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I.   IMTROZ'UCTION 

This  thesis  addresses  the  design  and  partial 
implernenta  ti  on  of  a  memory  manafe-er  for  a  mernter  of  thp 
family  of  secuiet  dis  tri'butpi ,  nul  ti-micrcprocessor 
operating  systems  desi^rned  bv  Richardson  and  O'Connell  [l]  . 
The  memory  manaf^er  is  responsible  for  the  secure  manai^-ement 
of  the  mair  memory  and  secondary  storafe.  The  memory  manaf^er 
design  was  approached  and  conducted  with  distributed 
processing,  mu  It  i-processine  ,  conf  igr.rat  ion  independence, 
ease  of  change,  and  internal  computer  security  as  orir-ary 
goals.  The  problems  faced  in  the  design  were: 

1)  Cevelopinp-  a  process  which  would  securely  manage 
files  in  a  multi-processor  environment. 

2)  Ensuring  tnat  if  secondary  storage  was  inadvertantly 
damaged,  it  could  usually  be  recreated. 

3)  Minimizing  secondary  storage  accesses. 

4)  Proper  parameter  passing  during  interprocess 
communicat  i  en. 

5)  revelopin.c  a  process  with  a  loop-free  structure 
which  is  configuration  independent. 

5)  Designing  databases  wnich  optimize  tn^  memory 

management  functions. 
The   proper   design   and   implementation   of   a    memory 
manatP-ement   process   is   vital   because   it   serves   as   the 
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interface  tetween  the  physical  stora^'e  of  files  in  a  storc^e 
system  and  the  logical  hierarchical  file  structure  as  viewed 
by  the  user  (viz.,  thp  file  system  supervisor  desip-n  "by 
Parks  [^]  ^ .  If  the  memory  manager  process  does  not  function 
properly,  the  security  of  that  system  cannot  he  guaranteed. 

The  secure  family  of  operating  systems  designed  ly 
Richardson  and  O'Connell  is  composed  of  two  primary  modules, 
the  supervisor  and  the  security  kernel.  A  sutset  of  that 
system  was  utilized  in  the  design  of  the  Secure  Archival 
Storage  System  (SASS).  The  design  of  the  SASS  supervisor  was 
addressed  hy  Parks  [2] ,  while  the  security  kernel  was 
addressed  concurrently  by  Coleman  [3].  The  SASS  security 
kernel  design  is  composed  of  ^wo  parts,  the  distributed 
kernel  and  the  non-distributed  kernel.  The  desi.o-n  of  the 
distributed  kernel  was  conducted  by  Coleman  [3],  and 
processor  manas-ement  was  implemented  by  Eeitz  [^]  .  This 
thesis  presents  the  design  and  inplemer  ta  t  i  en  cf  f'^e 
non-distributed  kernel.  In  the  SAS3  desii^n,  the 
non-distributed  kernel  consists  solely  of  the  memory 
manap-er . 

The  design  of  the  memory  manager  and  its  data  bases  va-^ 
completed.  The  initial  code  was  written  in  FLZ /SYS ,  but 
could  not  be  compiled  due  to  the  lacic  of  a  PIZ/SYS  compiler. 
A  thread  of  the  high  level  code  was  selected,  hand  compiled 
into  FIZ/A^*^,  and  run  on  the  Z30'20  developmental  module. 
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The      PI^/AS^      thread      lis  tin?-;      is      presented      as      a    c  err  put  en 
pro^raiT  appended    tc    this    thesis. 

A.   SACKGROUMD 

Operating  systems  were  initally  developed  durinr  an  era 
when  hardwane  was  a  scarce  and  expensive  resource,  while 
software  was  relatively  inexpensive.  The  initial  systerr 
design  technique  was  to  l)e,?in  with  the  hardware 
ccnf  i2:ura  tion  and  to  build  the  operating  system  upon  it.  The 
""botton  up"  design  technique  was  practical,  tut  it  rr^ade  the 
operating  systen  extremely  hardware  dependent.  Hardware 
configuration  changes  would  often  force  a  najor  software 
redesiPtn,  "but  as  lors:  as  hardware  costs  were  cioniinant, 
software  rrodif  ica  t  ion  was  the  logical  alternative,  .^s  the 
:^unctions  rpquired  of  the  operating  systen  increased,  new 
procedures  were  haphazardly  added  to  the  operatinf^  syster, 
often  introducing  new  problems.  (Maintenance  and  debugging  cf 
the  operating  system  became  extremely  cumbersome  and  time 
consumi  ng . 

The  increased  usage  of  computers  in  such  fields  as 
finance  and  sensitive  information  handling  uncovered  a 
seriou"^  problem  with  most  operating  systems.  Information 
stored  within  a  computer  system  was  p-enerally  quite 
accessible  to  anyone  who  had  a  working  knowledge  of 
operating   system  design   and   structure,  regardless  cf  any 
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ad-hoc  atterpts  to  provide  internal  computer  security.  Data 
stored  in  information  systems,  with  security  added  in,  could 
not  ^e  certified  as  'oein^  totally  secure[14]'. 

F.ecent  technolo^'ical  developments  have  reversed  the 
economics  of  the  computer  design  environment. 
Microprocessors  have  become  atundant,  powerful,  and 
inexpensive.  The  relative  cost  of  softvar'^,  or  the 
otherhand,  has  steadily  increased  until  it  now  dominates  the 
overall  cost  of  a  computer  system.  This  reversal  has  two 
basic  implications.  First,  software  must  be  treated  as  the 
expensive  commodity.  Software  developed  should  therefore  be 
logical,  easy  to  read,  relatively  maintenance  free,  and  easy 
to  debuf.  Second,  more  powerful  hardware  can  be  u^ed  to 
perform  functions  previously  performed  with  software,  and 
thus  hardware  (multiprocessors)  can  be  utilized  to  achieve 
overall  system  speed  poals. 

The  SASS  was  developed  utilizing  a  "top  down"  desit"n 
technique,  with  information  security  as  a  primary  cesi^-n 
issue.  Security  was  desie*nea  into  the  system  based  upon  the 
security  kernel  concept  [5].  The  security  kernel  provides  a 
secure  environment  by  ensuring"  that  just  one  element  o''  the 
system  (the  security  kernel)  is  sufficient  to  provide  the 
internal  system  security.  All  accesses  of  data  stored  witnin 
the  computer  system  must  be  validated  by  the  security 
T^ernel . 
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p.   "BASIC  CONCEPTS/DEPINITIOKS 
1 .   Process 

Or^anick  [6]  defines  a  process  as  a  set  of  related 
procedures  and  data  under^oinp-  execution  and  rianipulat  i  on  , 
respectively,  "by  one  of  possibly  several  processors  of  a 
computer.  The  process  is  a  logical  rather  than  a  physical 
entity,  and  can  he  vieved  as  a  set  of  related  procedures  and 
data  (referred  to  as  the  process'  address  space)  aV'd  a  print 
of  execution  within  thiat  address  space.  Each  process  rr>ay 
have  associated  with  it  such  lo^^ical  attrihutps  as  a 
security  class  authorization  and  a  unique  identifier.  In 
order  to  execute,  the  process  must  he  rapped  onto  (hound  to) 
a  physical  processor  within  the  corputer  systerr:. 

A  process  r^ay  exist  in  one  of  three  states:  ■blo':~>:ed, 
ready,  or  running.  Vnen  in  a  Llocked  state,  the  process  rust 
wait  for  the  occurrence  of  some  event  before  execution  can 
continue  (for  example,  an  access  of  secondary  storap-e^.  'Vhen 
the  ev'=nt  for  which  a  blocked  process  is  waitin,?  occurs,  the 
process  is  placed  into  the  ready  state  which  indicates  that 
the  process  can  run  when  a  processor  is  available  to  be 
assigned  to  it.  The  process  is  in  th^  running  state  when  it 
is  executing  on  a  processor. 
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2  .   Prcess  Switch  in.? 

Vhen  a  process  is  tlociced,  the  physical  Drocesscr 
upon  which  it  is  scheduled  is  idle.  For  efficiency  recsons, 
it  makes  sense  to  freeze  that  process,  save  the  exe-^ution 
point  (prof'ram  status  registers,  pro^*ram  counter,  execution 
stack)  ar.<i  the  address  space,  and  then  schedule  another 
process  to  run  on  that  processor.  This  is  referred  to  as 
process  switching  (or  mul  ti  prcgramring )  ,  and  is  an  irrportart 
aspect  of  a  distributed  operatin.?  syster.  The  overall 
system,  such  as  S.ISS,  can  be  viewed  as  a  set  of  cocpe rating 
processes  that  interact  to  perform  t^.e  intended  functions. 

Efficient  process  switching  can  only  te  achieved 
with  the  supiDort  of  sor-e  hardware  switching  mechanism  that 
will  unload  the  "blocked  process'  address  space,  and  load  the 
address  space  of  the  scheduled  process.  Some  systems  have  a 
rip.  (descriptor  base  register)  which  is  used  to  point  to  a 
list  cf  multiple  a'^dress  spaces  (one  per  process)  which 
exists  in  memory.  Thus  to  change  an  address  space,  the  EPR 
need  only  be  changed.  The  £ASS  utilizes  a  Z-cP^k:'  supporting 
hardware  device  entitled  a  f^emory  i-'anae.'ement  '^nit  Cf-'i-'TJ)  to 
allow  efficient  process  switching.  The  MiS'J  consists  of  a  set 
of  registers  (64  or  1??  in  the  ?ASS  design)  which  contain 
the  process'  address  spa^^e.  Thus  process  switching  would 
involve  the  switching  of  control  to  another  hardware  i^r^U  (if 
a   hardware   I^MU   were   available   for   each   process),   or 
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alternately  loading"  a  software  MMU  irra^e  (whirh  is  always 
i^ept  current)  into  the  MM-J  whenever  a  process  switch  is 
required.  The  SASS  currently  maintains  a  software  ^^U  ira^^e 
for  each  process. 

3.   Protection  Domains 

A  user's  process  executing  on  a  computer  system  has 
an  address  space  which  includes  the  user  provided  procedures 
and  data,  and  also  those  portions  of  the  distrituted 
operating  system  which  are  required  to  support  execution  of 
his  program.  To  maintain  system  integrity  and  security,  it 
tecomes  mandatory  to  protect  the  operating"*  system  from  ■being- 
altered  or  manioulated  by  the  user's  procedures.  To  achieve 
this,  the  process'  address  space  is  divided  into  a  set  of 
hierarchical  domains  which  ensure  that  the  segments  of  the 
operating  system  are  orotected  from  the  user.  Since  the  top 
down  design  cf  the  operating  system  provides  a  strict 
hierarchal  structure,  the  domains  of  the  operatinp-  system 
are  also  hierarchical  in  structure  (viz.,  are  protection 
rings).  In  the  design  cf  the  secure  operating  system  family, 
three  domains  were  defined:  the  user,   the   supervisor,   and 

the  kernel. 

Operating  system  segments  which  mana^-e  the  actual 
shared  physical  resources  reside  in  the  kernel.  Th^  ^-'rernel 
is  the  most  privileged  domain  of  the  address  space.  It  can 
"be  envisioned  as  a  mini-o  Derating"  system  that  does   all   the 
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resource  management.  The  security  kernel  se^-ments 
( executa'ble )  can  only  "be  accessed  within  the  kernel.  Global 
(system  vide)   data   "bases  are  restricted  to  access  ty  only 


the   security  kernel   to   prevent   the   possi^bility 
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unauthorized  inter-prccess  leakage  of  information  ["^j  . 

The   supervisor   domain   resides   hetween   the   most 
privilef?ed  kernel   domain  and   the   least   privile^-ed   user 


domain.   The   supervisor   contains   those   segments 
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operating  system  which  are  rec^uired  to  provide  such  common 
services  as  creatine*  a  hierarchical  file  system.  The 
supervisor  deals  with  the  logical  entities  (segments^  as 
viewed  by  the  user,  and  manae^es  these  se4?ments  by  calls  to 
the  kernel.  To  preserve  the  integrity  of  the  file  system, 
the  user  is  placed  in  the  least  privilep-ed  domain,  and  can 
communicate  directly  with  the  supervisor  only. 

Multiple  nrotection  domains  may  be  implemented  via 
either  a  hardware  and/or  a  software  ring  strvcture.  A 
hardware  implementation  is  more  efficient,  however  the  VLSI 
microprocessor"^  currently  being  manufactured  provide  for 
only  two  protection  d^^mains.  The  present  design  cf  the  SASS 
requires  two  domains,  separating  the  supervisor  and  the 
security  kernel.  The  Z8?f'0  microprocessor  prcvidps  the  Si^.SS 
with  the  hardware  ring  structure  by  providing  two  execution 
n^odes,  the  system  mode  and  the  normal  mode.  The  kerrel 
executes  in  the  system  mode  and  thus  has  access  to  all 
segments,  machine  instructions,  and  hardware  facilities.  The 
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supervisor  executes  in  the  nornal  rrode,  and  thus  only  has 
access  to  a  sutset  of  the  instruction  set  and  se^^nents.  The 
supervisor  does  not  have  access  to  those  instructions  which 
manipulate  the  system  hardware,  such  as  special  I/O  and 
execution  n^ode  control  instructions. 

4.   Se^nentation 

Se^rrenta  t  i  on  is  the  key  element  of  a  secure  systen. 
A  segment  is  a  lof'ical  grouping  of  informatior  such  as  a 
procedure,  array,  or  data  area  [S] ,  The  address  spare  of  a 
process  consists  of  those  segments  that  nay  he  addressed  hy 
that  process.  Se,£:mer  tation  is  the  manaf^pmen  t  of  these 
segments  within  the  address  space.  In  order  to  address  a 
specific  location  within  a  sei^mert  two  dinensicns  are 
required,  an  identification  of  the  ses-n^ent  fe.^.,  ses-rrent 
numher)  and  an  offset  from  the  base  of  the  segment. 

Each  ses-ment  may  have  several  l0i?ical  attributes 
associated  with  it.  These  attritutes  can  include  segment 
size,  classification,  and  access  permitted  (r^^ad,  write, 
execute).  T'he  physical  attributes  of  a  segment  include  the 
current  "base  address,  and  whether  or  not  the  segment  is  "in 
core".  The  segment's  attributes  and  its  physic^al  location  in 
memory  are  contained  in  a  segment  descriptor.  The  segment 
descriptors  for  a  process  are  often  contained  in  a 
descriptor  list  (viz.,  an  r^MU  image  for  the  SP.SS)  to 
facilitate  the  memory  management  of  its  address  suace. 
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Segr^enta^ion  permits  multiple  processes  to  share  a 
single  secernent  and  to  avoid  the  requiremeixt  of  mai  ntainir.p- 
duplicate  copies  in  rremory.  This  eliminates  the  possilility 
of  havin,^  conflicting  data  when  multiple  copies  of  the  sap.e 
segment  are  maintained.  Sep-mentat  ion  also  enatles  the 
enforcement  of  controlled  access  to  a  particular  segment , 
since  each  process  can  have  different  access  (read/write)  to 
stored  see-ments.  This  capatility  of  enforcing  controlled 
access  is  crucial  to  S'=curit7. 


Segmentation    Drovides 


mechanism   for   the 


virtualizat  ion  of  memory  (althou^rh  not  provided  in  the 
SASS).  If  a  user  requests  access  to  a  segment  to  iwhich  he 
has  access  ri,?hts,  an;^,  that  segment  is  not  in  main  memorv,  a 
memory  fault  will  occur  which  will  cause  that  se^^ment  to  "he 
loaded  into  main  memory  (another  se^-ment  mav  have  to  te 
moved  to  s'=condary  storage  to  make  room).  Thus  tc  the  user, 
the  size  of  main  memory  is  virtualized  into  the  size  of  the 
process'  address  space. 


5.   I  n:f'orma  tiOL  Security 

■         ■,■■■■- ■■■   I    I—- ■■■■iV^ 


As  previously  stated,  there  is  an  ever  increasing 
demand  for  a  computer  system  to  provide  for  the  secure 
storage  of  information.  This  security  cannot  le  added  to  an 
existing  operating  system  with  a  large  degree  of  confidence 
that  the  resulting  security  system  cannot  he  avoided  or 
hypassed.   In   order   to   te  demonstratly  adequate,  security 
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rrust  "be  desi<^ned  into  the  operating  system,  and  rust  >e  part 
of  the  cornerstone  upon  which  the  operatinp-  systerr  is  built. 

Thpre  are  two  "basic  aspects  of  information  security, 
external  security  and  internal  security.  External  security 
prevents  an  infiltrator  from  getting  to  the  object  in  which 
the  desired  information  is  stored.  This  can  te  of  such  form 
as  a  fence,  a  safe,  a  sentry,  or  a  guard  dog.  If  an 
infiltrator  rrana.ees  to  penetrate  these  external  se'-urity 
measures,  he  then  has  access  to  the  desired  information. 
Internal  controls  would  consist  o^  those  security  measures 
internal  to  the  computer  which  impede  and  if  effective, 
prevent  a  compromise  of  information.  If  the  internal 
controls  function  properly,  information  is  provided  and 
exchanged  only  with  the  users  wnc  are  explicitly  authorized 
access  to  that  information.  Many  information  systems  are 
required  to  store  and  access  information  of  different 
security  levels  (e.^.,  secret  files  interspersed  with 
confidential  and  unclassified).  The  internal  security  of 
such  a  "multilevel"  system  must  permit  users  and  inforraticn 
to  exist  simultaneously  at  different  security  levels,  ard 
also  ensure  that  no  unauthorized  accesses  (either 
intentional  or  unintentional)  are  permitted.  The  SASS  was 
designed  to  provide  a  multilevel  secure  storage  environment. 

The  data  to  ce  stored  in  a  secure  information  system 
can  he  looked  upon  as  a  set  of  logical  objects  such  as  files 
or  records.  Associated  with  each  of  these  objects  is   a   set 


20 


of  SDtjects  which  have  access  ri^-hts  to  that  olject.  These 
access  rights  may  include  read  access,  write  access,  or  a 
combination  thereof.  The  non-discretionary  security  policy 
involves  rneckin^  the  ohject's  access  class  (oac)  with  the 
subject's  access  class  (sac)  to  ensure  that  they  are 
ccrrpatible.  The  access  perr^itted  is  defined  in  a  lattice 
model  of  secure  information  flow  [9]  as  follows: 

sac  =  oac,  read  and  write  access  permitted 

sac  >  oac,  read  access  permitted 

sac  <  oac,  no  access  permitted 
The  government  security  classification  system 
provides  an  example  of  a  non-discretionary  security  policy. 
A  user  with  a  security  clearance  of  confidential  is 
authorized  read  and  write  access  to  a  confidential  file  (sac 
=  oac),  and  he  has  read  access  (tut  not  write)  to  an 
unclassified  file  (sac  >  oac).  This  restriction  on  write 
access  is  to  prevent  the  inadvertant  writing  of  confidential 
data  into  an  unclassified  file  to  which  the  suhje^t  may  have 
sinrl taneous  access  (this  property  is  often  referred  to  as 
the  '"'-property  [10]).  Finally,  the  confidential  sutjert  dc^s 
not  have  access  to  any  secret  files  fsac  <  oac). 

Th«  discretionary  security  policy  involves  checkir.^ 
the  subject  a<?ainst  an  object's  access  control  list  'ACL'. 
The  subject  only  has  access  to  an  object  if  he  is  included 
in  its  ACL.  This  policy  is  anala^-ous  with  the  p-cvernment 's 
'need   to   know"   policy,   wnicn   precludes  a  subiect  with  a 
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secret  clearance  from  having  access  rip-hts  to  all  secret 
information  within  the  system.  He  may  access  only  that  for 
which  he  has  a  "need  to  Y.rov"  ,  The  discretionary  security 
policy  thus  allows  the  users  of  the  system  to  specify  who 
has  access  to  their  files.  It  is  noted  that  the 
discretionary  security  policy  is  a  refinement  of  the 
security  policy,  and  never  permits  a  violation  of  the 
non-discretionary  security  policy  in  effect. 

The  SASS  was  designed  with  the  internal 
non-discretionary  security  to  he  provided  "by  the  security 
kernel.  Discretionary  security  is  provided  ty  the  supervisor 
file  system.  The  security  kernel  is  "based  upcn  a 
mathematical  model  which  has  teen  proven  correct.  This 
mathematical  model  implements  the  system's  security 
policies . 

The  security  kernel  design  has  thre'=  prerequisites 
in  order  to  provide  a  secure  environment:  1  "•  the  kernel  must 
■^e  isolated  to  ensure  tnat  it  cannot  be  mc^ified  eitner 
intentionally  or  inadvertantly.  This  is  to  ensure  that  the 
"behavior  of  the  kernel  cannot  "be  modified.  2)  Each  and  every 
attempt  to  access  lata  within  the  system  must  invoke  the 
kernel.  3)  The  kernel's  correctness  must  be  verifiable.  This 
implies  that  the  mathematical  model  must  be  proved  and 
demonstrated  as  secure,  and  that  the  kernel  implements  this 
model . 
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C.   THESIS  STP.l' CTUR2 

This  thesis  presents  the  detailed  design  of  a  remory 
ranagsrrent  Drocess  for  the  3ASS  .  The  top  down  design 
technique  was  utilized,  with  levels  of  alstraction  used  to 
reduce  the  d'=sign  complexity.  The  high  level  lan^Udf^e 
utilized  was  PIZ/3YS,  which  was  desip-ned  to  "be  coirpati'ble 
with  the  Zc?ei  microprocessor.  ?I2/ST£  is  a  "block  structured 
lanffua/?e  similar  to  PASCAL.  The  compiler  which  compiles  from 
PIZ/SYS  tc  the  Za^ei  instruction  code  is  still  in  the 
developmental  sta^e  at  ZILCG,  INC.  The  PIZ/SIS  code  had  to 
therefore  be  "hand  compiled"  ( vi z .  ,  tra nsla ted  to  the  PIZ/ASM 
assembly  lanffuar-e)  in  order  to  run,  test,  and  detufi-  the 
code.  Some  of  the  procedures  in  the  lower  levels  of  desi^-n 
(those  which  use  privile,^;ed  instructions  to  directly 
manipulate  the  system  hardware)  must  he  directly  coded  usin^- 
the  assembly  cod^  rlZ/ASM.  These  procedures  were  declared 
external  to  the  >'emory_!^anag.er_PLZ /SY3_r;odule  and  are  coded 
in  the  Memory_Mdna^;'er_?LZ /ASi'_''^odule  . 

Chapter  II  of  the  thesis  presents  an  overview  of  the 
SA5S  at  its  current  stage  of  development.  The  design  of  tne 
memory  management  process,  and  the  concurrent  implementation 
of  the  ■distributed  kernel  processor  management  by  P-^itz  [4] 
refined  the  original  design  of  Parks  and  Coleman.  Puture 
wrrk  in  the  SASS  v/ill  most  lilrely  require  some  refinement  of 
the  "ore sent  design. 
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Ch^-pt«=r  III  prosFT-ts  the  detaile'^  d^sii^r  cf  the  rerory 
manap-er  n^cduls.  This  chaTjter  emphasizes  why  certain  desi-T. 
features  w°re  rhosen,  and  how  they  were  ipplerrented  in  this 
design. 

The  final  chapter  presents  the  status  of  research  to 
(fate,  and  atterrpts  to  identify  what  follow-on  wor!':  is 
required.  The  PLZ/SYS  code  module  and  the  PIZ/AS.^  code 
module    are    presented    as    a^Dendices. 
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II.   S?C^T?.g  AHCHIVAI  STORAGj:  S^STIM  TiSICrN 

This  chapter  presents  an  overvip'*  of  the  SASS  in  its 
current  state  of  developmtnt .  It  is  a  srrnmction  of  the 
orif'inal  desif^r.  efforts,  and  refle'^ts  ref inerren t s  of  those 
oririnal  designs.  This  cve-rview  is  necessary  in  order  to 
fully  understand  the  interrelationship  ■b'=tween  the  merrory 
franafer  and  the  overall  systen  desis-n.  It  also  provides  a 
current  "base  for  further  SACS  deve  lopnent . 

The  purpose  of  the  S\SS  is  to  provide  a  secure  archival 
file  storage  riediurn  for  a  variable  nr.rnher  of  host  '^crputers. 
The,  'iev  '^esi^'rn  e^oals  of  the  SASS  '.\^ere  riuiti-level  internal 
computer  se'^urity  and  controlled  sharing  of  data  a7:0np' 
authorized  users. 

Fii^ure  1  provides  an  exar:ple  of  hew  the  S.^SS  could  he 
used.  In  this  exanpie,  there  are  four  host  computers  vhich 
reside  in  four  separate  rooms  (consider  each  of  these 
computers  to  "be  microcorrputers  ,  althoua:h  any  computer  could 
"be  utilized).  lach  of  the  four  hosts  are  used  to  create  and 
manipulate  files  of  fixed  predetermined  security 
classification.  For  example,  all  file^^  created  ty  host  ^2 
are  classified  secret.  Host  n2     cannot   create   top   secret. 
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confidential,  or  unclassified  files  ''nor  can  he  ccces-^  top 
secret  in  ^his  example).  Access  to  eacn  cf  taese  rcrrs  is 
ph/sicclly  controlled  to  ensure  that  only  personnel  with  t^e 
proper  security  clearance  are  authorized  access.  Nme  cf  tne 
host  systems  have  a  perrranent  local  file  storage  device,  and 
all  ar°  hard -wired  to  an  I/O  port  of  the  SASS. 

Each  host  controls  the  access  to  its  I/O  ports  (host  ^4 
illustrates  the  rulti -level  host  'connection  currently 
required  "by  the  SAS3K  The  physical  protection  cf  the 
hard-wire  is  a55urrrrf=d  to  "be  adequate  to  irinirize  tne 
possibility  of  such  ralicious  activities  as  wire  tappin?"  or 
emanations  T'onitorin.r.  Once  a  user  of  the  host  s^sten 
corrpletes  his  work,  he  can  permanently  store  his  file  en  the 
"ASS,  which  is  contained  in  the  fifth  room  of  fi^'ure  1  (view 
the  SAS3  as  an  ZS^Cl  nicroconputer  with  access  "t'O  se'^ondary 
«torat"e  devices).  To  e^ain  access  to  a  file,  the  user  or  0 '''S 
of  the  host  system  nust  request  the  SASS  to  provide  hirr:  wit^ 
that  file.  This  irr, plies  that  if  a  malicious  user  ^ains 
accpss  of  the  confidential  nost  syster-,  he  still  cannot 
access  files  o^  a  higher  classification. 

The  SASS  must  le  c  a  pa  hie  of  performinp""  three  hasic 
functions  in  this  environment.  These  functions  are:  1^  store 
a  file  for  a  host  system,  2)  retrievp  a  file  for  a  nost 
system,  and  3)  ensure  that  the  the  files  are  made  availahie 
only  to  authorized  users.  The  required  capabilitv  of  file 
stora^^e   and  retrieval  implies  that  processes  must  exist  fcr 


27 


each  host  sy^ten  to  perform  file  mdnaeenent  end  data 
trarsf^r  or  "behalf  of  that  host.  To  ensure  the  securitv  cf 
the  stored  information,  the  5A3S  .'riust  ensure  that  the  user 
of  a  specifir  host  systeri  may  only  address  th=  files  *c 
which  he  has  access.  The  SAS.^  achieves  the  desired 
environr^ent  throui-;h  a  d  i  s  trituted  opp'rating  system  desi,?^ 
which  consists  cf  two  primary  nodules*  the  supervisor  and 
the  security  Verne  1  (the  securitv  kernel  actually  consist? 
of  distributed  and  non-di  strihuted  portions),  ^.cich  host 
systen,  which  is  hardwired  to  the  SASS  ,  communicates  with 
its  own  I/O  process  ar''  file  manager  nrocess  in  the  SASS 
itself. 

The  supervisor  is  responsible  for  tne  SASS-ncst  system 
interface.  It  constructs  ^r^d.  manages  a  hierarchical  file 
system  for  its  host,  hased  upon  th^  files  which  the  host  has 
submitted,  and  controls  the  actual  I/O  (both  data  and 
commands)  between  the  SASS  and  the  host  5yst«^rr.  The 
supervisor  is  built  upon  the  security  kernel  and  performs 
the  host's  requests  (file  sto^a^-e,  file  retrieval.  I/O)  re- 
calls to  the  security  kernel.  These  calls  must  be  validated 
(by  a  fate  keeper  module  in  the  SASS  design)  before  the 
security  kernel  function  is  invoked. 

The  SASS  securitv  kernel  consists  of  a  distributed  and 
non-distributed  kernel.  The  distributed  kernel  is 
distributed  to  (viz.,  is  in  the  address  space  of'  every 
process,  and  is  recporci>)le   for   the   multiplexing   of   t'-.e 
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several  processes  onto  the  act^ial  har'iw^re  pro^^ess  orf  s '' , 
^nforcin£"  the  non-dis  creti  oriary  security  policy.  and 
providirifir  the  synchronization  prir.itives  for  inte  r-DiO'^ess 
cornmuni  cat  ion  .  The  non-dist  rihuted  kernel  consists  of  the 
merory  pianaser  process  vhich  is  resDonsihle  for  the  secure 
manae'erTient  of  "both  rrain  memory  and  secondary  storcpe.  Each 
hardware  processor  rnust  have  its  own  rer.ory  manager  (erp'C, 
non-distributed   kernel)    in    the   SA??    de^i^n. 

An  abstract  system  overview  of  the  SASS  is  presented  in 
figure  2.  Four  levels  of  abstraction  were  utilized  to 
simplify    the   desi^^n   and    unders  tandabi  li  ty   of    the    system. 

Level  ?  consists  of  the  system  hardware  which  inclrdes 
the  Z8r?l  microprccesscr,  the  local  and  global  nemnries,  s^v.t 
secondary      storare.      The      ^ASS      is      desi^^ned    to    orerate    in   a 


multi-microurc cesser      environment,      therefore      eacn 
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a^^si^'ned  its  own  local  memory  (to  which  it  alone  has  access^ 
in  which  it  can  store  process  local  se^^ments.  The  system 
contains  a  ^--lobal  memory,  which  every  CPU  may  access. 
Segments  to  which  a  user  process  has  write  access  must  be 
stored  in  global  memory  if  more  than  one  proce<^s  has 
simultaneous  access  to  that  segment.  Tnis  is  to  ensure  that 
all  processes  access  the  current  copy  of  that  shared 
writable  segrrent.  The  basic  storage  policy  is  to  stcr«=  every 
segment  within  local  memory  if  at  all  possible.  This  is  to 
keep  bus  contention  between  processors,  wnicn  access  global 
memory,  to  a  minimum. 
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Figure  2.  SPSS    Abstract  System  Overview 
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Level  1  consist?  of  the  distritut ei  and  non-di s t riluted 
>ernel .  ThP  kernpl  is  placed  in  (executes  in)  the  rest 
privilep-ed  dorain  (systern  rr.ode)  of  ihe  1^2Z1  to  ensure  that 
it  is  protected  frcm  an;/-  manipulation  (either  rialicicus  cr 
inadvertant '^  .  The  kernel  controls  all  access  to  the  systep 
hardware  hy  maintaining  all  privileged  machine  instructions 
within  its  domain.  Only  the  kernel  may  access  these 
instructions.  Th»  distrihuted  kernel  is  respcnsible  fcr 
creatine  a  virtual  processor  environment  and  enforcing'  the 
non-discretionary  security  policy.  It  multiplexes  processes 
onto  virtual  processors  and  then  multiplexes  these  virtual 
processor(s)  onto  the  actual  herdware  processors.  The 
non-dis t rihuted  kernel  consists  of  the  memory  manager  and  is 
responsible  for  the  secure  management  of  coth  main  memory 
and  secondary  storage. 

Level  2  consists  of  the  supervisor,  which  resides  in  the 
less  privileged  domain  (normal  mode)  of  the  1~2Z\ 
microprocessor.  It  has  access  to  all  the  ma'^hine 
instructions  with  the  exception  of  those  which  manipulate 
the  system  hardware.  The  supervisor  must  request  the  kernel 
to  move  segments  into  and  out  of  memory  and  secondary 
storas-e  via  the  gate  keeper  (a  software  assisted 
ring-cress  irg  mechanisr: )  .  The  supervisor  consists  of  two 
surrogate  processes  for  ecch  host,  the  I/O  f  input/output  "*■ 
Drocess  an^  the  7*A  (file  management)  process.  Py  utilizirg 
the   I/O   and  "^M  processes  the  su"oervisor  is  able  to  -orovide 
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and  marai^e  a  virtual  file  riie  rarciy  for  eacr.  hcst  system. 
Tach  hcst  syster  has  I/O  and  T^.  processes  created  and 
assi2"n'="i  at  syster^  ^^eneration.  They  are  r.ct  dyr.apically 
created  or  deleted.  The  supervisor  ensures  that  each 
segrrent's  c  i  scret  ionary  security  is  enforced. 

Level  3  consists  of  the  host  coiT,put'=r  systerrs.  These 
systens  are  hardwired  to  the  I/O  ports  of  the  Z600i?.  The 
hosts  comriunica  te  with  the  SASS  via  syster^  protocols  over  a 
co^imunica t  ion  link.  Any  computer  systen  could  serve  as  a 
host,  with  each  host  supnortin^  multiple  users. 

3.   SUPERVISOR 

Each  host  system  is  assis-ned  the  dedicated  services  of  a 
pair  of  supervisor  processes  at  system  i^enera  tion .  These 
Drocesses  are  the  I/C  and  I'-f  processes.  The  F"^  process  and 
the  I/O  process  communicate  with  each  other  via  a  shared 
segp-'ent  entitled  the  "railhox".  This  ccmruricat i  en  is 
synchronized  via  the  kernel  synchronization  primitives  vhi'-h 
act  upon  eventccunts  and  sequencer?  [12].  A  virtual  file 
system  is  created  and  maintained  for  each  host  ty  its  7"-^  and 
I/O  processes. 

1.   File  i'^ana°'ement  Process 

m  ' 

The   FM  process  is  responsitle  for  the  nana^-ement  of 
the  host's  virtual  file   system  wi*hin   the   SASS.   The   7M 
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proces?   interprets  all  the  host  commands  and  acts  upon  then 
in  conjunctic^  with  the  I/O  process. 

The  user  of  the  host  system  vievs  his  stored  data 
(within  the  SASS)  as  a  hierarchy  of  files.  Figure  3  provides 
an  example  of  such  a  hierarchical  file  structure.  To  specify 
a  particular  file,  a  -oathnaTP  is  required.  The  pathname  is 
simply  a  concatenation  of  the  file  names  (given  to  each  file 
"by  th*=  user  at  its  creation)  starting  at  the  "root" 
directory  ^nd  procedinr  sequentially  to  the  desired  file. 
The  user  is  required  tc  sutnit  a  pathname  with  pach  command 
sent  to  the  SASS.  The  five  "basic  actions  to  be  per-^ormed 
upon  files  at  this  level  are:  1)  to  create  a  file  (data  or 
directory),  21  to  delete  a  file,  3'^  tc  read  3  file  (data  or 
directory),  4)  to  initiate  or  modify  file  attributes  ''size, 
classification,  access  permiitedl,  and  5)  to  store  ^write'*  a 
file. 


The 


process  is  required  to  convert  the  pathnc 


provided  by  the  user,  into  one  or  more  segment  numbers.  Thi 


is  necessary  because  the  notion   of 


file   is   not   known 


within  the  kernel.  ^.11  files  are  composed  of  segments,  and 
must  be  referenced  as  segments  within  the  kernel  for 
manipulation  and  management.  The  F'^'  process  must  also 
provide  appropriate  command  handlers  to  ensure  that  the 
user's  requested  action  is  properly  carried  out. 

The   SASS   permits  a  host  tc  read  or  write  the  files 
of   another  host,   at    the   same   security   level,    if 
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Figure  3.   Virtual  File  Eierarchy 
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di  sere  ti  or.ary  access  is  perr'itted.  Files  of  a  Icwer 
classification  may  be  read  only  (if  discre t iona rv  access  is 
perTiitted).  This  file  shcrine  is  achieved  ty  creatine  a  link 
>'etwe'=n  the  two  file  hierarchies.  This  link:  is  entered  into 
a  directory  file  of  the  host,  and  is  constructed  in  the  sare 
rnanner  as  a  pathname  (viz.,  it  is  a  concatenation  of 
filenames).  The  kernel  enforces  a  read  only  access  to  the 
lower  classified  file=,  which  prevents  the  possilility  of 
writing  data  (through  a  link)  of  a  higher  classification 
into  a  file  of  lover  classification. 

The  database  utilized  by  the  J'-^  process  to  rar.dfe 
the  host's  ^iles  is  t'-^e  F^  Known  Segment  Table  (r^_KST'^.  The 
jyjlS'T  is  a  list  of  those  segments  wnich  are  known  to  'viz., 
within  the  address  space  of)  the  FM  process.  Firure  4 
provides  en  example  of  the  F^'_K!ST  structure. 

Whenever  a  user  of  a  host  system  requests  access  to 
a  specific  file,  the  F>'_I<ST  is  searched  to  determine  if  that 
pathname  (se<?ment)  is  already  known.  If  it  is  known,  the 
request  is  passed  to  the  kernel,  via  the  ?ate_keeper,  with 
the  appropriate  segment  number,  for  the  desired  action.  If 
the  pathname  is  not  known,  the  segment  number  of  the  desired 
file's  directory  (parent)  file  and  an  entry  number  are  sent 
to  the  kernel  with  the  requesi  to  make  that  segment  known. 
If  the  request  is  authorized  by  the  kernel,  a  segment  number 
and  access  mode  authorized  are  returned.  The  returned 
segment   number   and   mode   ar-e  then  entered  intr:  the  F^!  ''TST 
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Fieiure  4.   File  Manager  Known  Segment  Table 
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with  that  se^fr^erit's  pathnare.  Cncp  the  ser^nent  is  kucwl,  the 
desired  user  action  can  "be  carried  out. 

The  user  requests  to  create  cr  delete  files  are 
simply  passed  to  the  appropriate  kernel  procedure,  via  the 
prate  keeper,  hy  the  Fi"^  process  (after  a  discretionary 
security  check).  No  entries  are  added  or  deleted  from  the 
FM_?!ST  during  create  cr  delete  requests  (they  invoke  kernel 
priritives  which  add  or  delete  entries  from  a  kernel  data 
hase)  . 

Should  the  ?■'•  process  request  that  a  segment  he 
swapped  into  menory  and  memory  is  full,  an  error  rede  will 
he  returned  to  the  FM  process  from  the  kernel  (it  is  noted 
that  this  is  a  per  process  memory  allocation,  thus  f^.e 
memory  state  cannot  he  affected  hy  its  use  ty  other 
processes).  The  FM  process  will  then  select  a  segment  to  he 
removed  frop'  cor'='  to  make  room  for  the  desired  se-^ment  .  The 
current  de<;ifn  calls  for  the  invocation  of  a  least  recently 
use'*  algorithm  (LRU)  which  makes  use  of  the  F'1_KST  '"used" 
field  to  determine  the  least  recently  used  segment  for  swa-o 
out . 

liscre t ionary  security  is  enforced  in  the 
discretion  ay  security  module  of  the  FM  process.  An  acce<^s 
control  list  ( kCl)  is  maintained  for  earh  file  within  the 
file  hierarchy.  The  ACL  is  si'^ply  a  li<^t  of  authorized  u^^ers 
(a  refinement  of  non-di s- ret i onary  security^  which  is 
checked  for  each  access   to   that   file.   The   discretionary 
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security  rodule  also  perforrrs  the  housekeeping?  fur.'-ticns  for 
the  file's  ACL.  These  functions  include  the  eddition  of  a 
ACL  entry,  the  deletion  of  an  ACL  entry,  and  the 
initialization  of  an  ACL  for  a  new  file. 

It  is  noted  that  the  criminal  desi^r  of  the  FM 
process  contained  a  nemory  manager  procedure.  This  was 
necessary  "because  the  original  SASS  design  called  for  the 
parti  ti  oninf  of  mefrory  such  that  each  supervisor  Tcintained 
his  own  core.  The  FM  nerrory  rrana^ier  rranaged  this  virtual 
core  by  calls  to  the  kernel  via  the  ^-ate  keeper  (swap_ir, 
swap_out).  The  current  design  of  the  non-dis tri cuted  kernel 
includes  rerory  allocation  and  thus  has  removed  the  need  for 
the  supervisor  to  rr:ana(S;e  its  own  virtual  core.  recause  of 
this,  a  FK  rrenory  manafer  is  not  required. 

2.   Input /Out put  Process 

The  I/O  process  is  responsitle  for  all  the  input  and 
output  "between  th°  supervisor  and  the  hcst  rorrputer  syster'. 
The  I/C  process  receives  its  corrmands  fro'r'  the  T^"^  process 
via  the  shared  mailhox  segnent. 

T}ata  is  transfered  "between  the  hosi  systers  and  the 
S«ISS  in  fixed  size  "packets".  There  are  three  'oasic  tvpes  of 
packets,  a  synchronization  packet,  a  corrrand  packet,  and  a 
data  packet.  Protocols  exist  for  the  relia"ble  transmission 
and  receipt  of  the  pa^-kets  hy  "both  the  SASS  and  the  host 
syst*=rps.    The    current    design    calls   for   the   use   of 
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rrul  ti-packet  ijrotocols,  which   allows   the   sender   to   send 
several  packets  tefore  he  receive*^  a  receipt. 

The  ori:2:iral  design  of  the  I/O  urocess  rcrtained  a 
^emory  Manager  procedure  for  the  sarie  reasons  as  the  FM 
process.  This  procedure  is  no  longer  reqi:ired  due  to  the 
design  of  the  non-distrihuted  kernel. 

C.   DISTRIPUTED  ^EHNEI 

The  initial  design  of  the  security  kernel   as   presented 

"by  ColeTan  [2]  ,  has  been  developed  "by  Reitz  [4]  and  the  work 
presented   here.   The  primarv   refinements   have   teen   the 

replacenent   of  "block/wakeup   [3]    "by   event  counts,    t'^.e 

inclusion   of  an   event   rnancf-er   which   contains   the 

synchronization  prinitivp-s,   and   the    trarsfer   of    f^^l 

nana^ement   to  the   rerrory   maaa.s'er.   Figure   5  provides  an 

overview  of  the  security  kernel  desi<=sn. 

1.      C-ato   K^eTDer 

fc  «  _.i  ■■  ■■■■-I  » 

Th^  ^a  te  keeper  is  a  software  rinr?  crossin.^ 
mechanism  which  is  utilized  to  ensure  that  the  se-^urity 
kernel  is  isolated  and  tanperproof.  The  major  issues  of  the 
gatekeeper  desi^-n  are:  l)  to  provide  a  mode  swit'^hin? 
mechanism  for  switching  from  normal  ^supervisor)  mode  to 
system  (kernel)  mo-fe  ,  2)  to  mask  hardware  preempt 
interi'unt s  in  *he  kernel,  end   3)   to   check   for   "virtual" 
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software  -oreemiDt  ir.terrupts  when  l^avin^  the  kernel.  The 
s-ate  keeper  provides  the  sole  e.itrv  -DOint  into  the  kernel 
domain,  validates  the  request  and  its  ar^rnents,  and 
transfers  the  request  to  the  aptsropriate  kernel  procedure. 
If  the  rate  keeper  encounters  an  error,  it  ret-'jrns  an 
appropriate  error  code  without  invoking  the  kernel. 

The  ^ate  keeper  uses  a  parareter  tatle  to  validate 
the  user's  request  (call  by  value  only).  This  table  contains 
the  nurber  of  pararreters  required  by  each  kernel  function 
f creat?_segment ,delete_segment ,  etc.),  the  typ=  o^  each 
parameter,  and  the  type  of  each  return  parareter.  If  an 
error  is  discovered  during  the  validation  process,  it  sets 
the  return  rressa^e  to  &n  error  code.  If  t^e  request  is 
vali'i,  the  £;ate  keeper  calls  the  appropriate  kernel  rcdule. 

The  ^ate  keeper  is  a  trap  handler.  The  supervis'>r 
puts  an  ar^rumert  list  and  space  for  a  return  r<^ssar'e  in  a 
seferrrent  for  processor  rep'isters^  within  the  supervisor's 
domain.  Vhen  the  ^ate  keeper  is  invoked,  it  must  fir<^t  save 
the  supervisor  processor  re^^isters  and  then  retrieve  the 
ars'unent  list  fvia  an  argument  list  pointer  refisterK  The 
ar<?uments  are  validated  and  if  correct,  passed  to  the 
appropriate  kernel  nodule. 

Vhen  the  kernel  ccFpletes  action  taken  upon  the  user 
request,  it  returns  to  the  ^sate  keeper.  The  rate  keeper  then 
copies  a  return  rnessa,?^e  into  the  return  argun^ent  (that  is 
returned   to   the    supervisor's    donainl,    restores    the 
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supervisor's  envi  rorinpnt ,  unmasks  the  irterrupts,  d.r.d.  .Takes 
a  trap  return  back  to  the  suuerviscr  fviz.,  chan-^es  the  ^TOde 
tack    to    normal  'i  . 

2,      Sp^mer.t   '^a nailer 

The  segment  panaerer  is  responsille  for  the 
franat^er'en t  of  the  segmented  virtual  memory.  Tr.ere  are  sij 
functions  which  the  se^'ment  manager  is  called  upon  to 
perform.  These  functions  are:  l)  to  create  a  se/^ment,  2)  to 
delete  a  segment,  3)  to  make  a  segment  known,  ^)  to  make  a 
segment  unknown  (terminate),  5)  to  svau  a  segment  into  core, 
and  6)  to  swap  a  seguient  out  of  core. 

The  segment  manager  uses  the  finown  Segment  Tahle 
(ZST)  as  its  data  tase  to  manas-e  segments.  The  KST  is  a 
process  local  kernel  data  base  which  contains  entries  for 
all  the  ser-ments  which  the  process  has  made  known.  ri2"ure  6 
provides  an  example  of  the  rCST  structure.  The  Y.S'7  size  is 
fixed  at  system  p-eneration.  It  is  indexed  hy  segment  nrrhers 
which  are  assigned  by  the  segment  manager.  When  a  segment  is 
made  known,  a  "handle"  (the  concatenation  of  the  CTlobal 
Active  Segment  Table  (5_AST)  index  and  the  segment's  unique 
identification"^  is  returned  to  the  segment  manas-er  by  the 
memory  manager.  The  handle  is  a  system  vice  unique 
identification  that  is  assio-ned  to  ea-^h  active  segment 
fviz.,  active  in  the  G_aSTK  The  KST  provides  the  mapping 
mechanism   for   convertinp-   the   se  foment   number   into    the 
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segnent's  unique  handle .  The  use  of  the  unique  handle  ly  the 
rerrory  nane^er  is  what  perrits  the  contrclled  snarir.f^'  of 
se^^T'ents  hy  "oncurrent  processes.  Any  pro'^ess  which  requests 
to  ra^'-e  a  specific  se^r^ent  active  will  alvays  le  returned 
that  sePTnent 's  unique  handle.  Thus  any  one  seis^rr.ent  may  exist 
within  the  address  space  of  several  processes  fvith  a 
different  segn^^nt  nurber  in  each  process)  while  residing  in 
one  location  in  merory. 

The  SIZ^  field  of  the  KST  represents  that  segr-ent's 
size,  "^e^rents  exist  in  rrultiples  of  256  tytes  due  to  Z-ci'QH 
^r^U  hardware  constraints.  An  upper  hcund  upcn  the  see^r^nt 
size  is  fixed  at  systerr  greneration  by  the  desi^rn  parar^eter 
nax_se^rrpr  *_si  ze .  This  is  lirited  to  S5K  hyt^s  by  harr'warc. 
The  ACC??S_^^CTE  field  states  the  access  authorized  to  the 
se^rrent  (r^ad,  write)  ^y  this  process.  The  Ii\'_CO-.T  field  is 
set  when  a  process  successfully  requests  the  se^'ment  to  te 
swapped  into  cor«^.  Th^  CLASS  field  is  used  to  f;ive  the 
access  class  (e.^".,  secret,  confidential"!  of  the  sef^-r^ent. 

The  usual  sequence  of  invol-'in^^  the  sep^rent  nanap^er 
functions  ^by  the  supervisor"!  would  be  as  follows:  1  "^ 
C reate_Segrpnt  (this  will  invoke  the  mencry  manager  to 
assign  a  unique  identification  to  the  created  se^rnent  \  2) 
Make_Known,  which  will  place  the  seanent  irtc  the  KST,  and 
3)  Swap_In,  which  will  nove  the  se^ri^ent  fror  secondary 
storage  to  main  merory.  To  remove  a  sef?;nient  from  main  neno^y 
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to   secondary   storafi-e,   the   order  would  te  1)  Sv;dp_Out,  2) 
"^c'f  e_^^r.k:nown  ,  and  3)  r'elete_Se^'nent  . 

3.   Event  Mana^ier 

The  event  mande'er  provide?  the  kernel 
synch rcni za t icn  priritives  that  are  used  for  the 
synchronization  of  concurrent  processes  in  the  supervisor  of 
the  present  SASS  design.  The  synchronization  nechanis^'  used 
is  that  of  pventcounts  and  sequencers,  first  proccsed  by 
Peed  and  Kanodia  [!£].  The  use  of  eventcounts  dnc  sequencers 
allows  the  ordering  of  events  to  ^^e  '•ontrolled  directly  hy 
the  processes  involved,  rather  than  to  depend  upon  rutual 
exclusion  mechanisns  such  as  senaphores.  The  actual 
eventcounts  are  rraintained  in  the  merory  manager  rrodule  as 
they  are   a  system  vide  entity  and  are  not  process  local. 

Heed  and  Kancdia  define  an  eventccunt  as  an  chject 
that  >eeps  a  count  of  the  nunter  of  events  in  a  i^articula" 
class  that  have  occurred  sc  far  in  the  execution  of  the 
systerr.  The  event  chserved  can  "be  anythinp-  frorr  the  input  cf 
data  to  the  system,  to  writing  a  particular  sef/rrent.  The 
eventcount  can  "be  viewed  as  an  integer  value,  which  is 
incremented  with  each  occurrence  of  the  observed  event.  The 
primitive  AFVANC^fX)  is  used  to  sip-nal  the  occurrence  of  a 
particular  event,  and  causes  the  eventcount  X,  associated 
with  that  event,  to  he  incremented.  The  primitive  HEAIfZ'' 
will   return   the   value   of  the  eventccunt  X.  The  nriritive 
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iiiAIT(I,n)  will  suspend  the  calling:  urocess  until  the  value 
of  eventcount  X  is  freate^  than  or  equal  to  the  integer 
value  n . 

A  sequencer  can  le  defined  as  an  abstract  ctject 
that  can  le  utilized  to  totally  order  the  event?  of  a 
particular  class.  The  "basic  purpose  cf  the  sequencer  is  to 
provide  a  means  to  determine  an  orderine  of  a  set  of 
occurences  cf  a  particular  event.  Ii>e  the  eventcount,  the 
sequencer  can  te  viewed  as  a.n  interer  value  which  is 
incren"=nted  each  time  the  primitive  TIC?"iT(5)  is  called.  The 
TIC\iT  primitive  is  tased  upon  the  ticket  machines  often 
used  in  tar'bershcps  and  ice  crpa.T  stores.  When  a  customer 
enters,  he  takes  a  ticket*  from  which  the  order  cf  w^o 
arrived  first  and  whom  will  he  served  rejt  can  he 
determined . 

The  use  of  eventcount'^  and  sequencers  hy  the  5ASS 
supervisor  can  he  illustrated  as  follows.  Suppose  that 
segment  A  is  currently  tein^'  updated  "by  process  one. 
3Cventcount  A  currently  has  the  value  o^  9  (the  eventcount 
associated  with  the  readini?  of  se^-ment  A).  Proce'^s  two 
desires  to  read  se^^ment  A,  so  he  ohtains  a  tic'^tet  "by 
utilizing  the  TICKET  primitive  a5Socia*;ed  with  se^-ment  k. 
The  value  returned  hy  "TICKET  is  1£.  Process  two  no*  calls 
upon  the  primitive,  Aa'AIT(  A ,  IZ )  ,  which  will  suspend  process 
two  until  eventcount  A  is  valued  at  If.  7hen  process  one 
completes  his  update,  he  will  execute  ALVANC5(A),  which  will 
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incr'=nent  eventccunt  A  to  tne  value  rf  10.  This  will  allcw 
the  AWAIT(A,ir'  to  return  to  process  two,  which  will  therx  le 
flllowp''  tc  read  segrrent  A. 

4.   Traffic  Controller' 

The  traffic  rontrcller  ;oerfcrrs  tne  furction  of 
scheduling  processes  to  run  on  virtual  processors.  The 
traffic  controller  could  le  designed  to  sch edible  processes 
to  run  directly  on  the  hardware  processors,  hvt  in  this 
desifn,  Keed 's  [11]  notion  of  a  two  level  traffic  controller 
was  utilized.  Thus  the  processes  are  first  multiplexed  onto 
virtual  processors  ty  the  traffic  controller.  The  virtual 
processors  are  then  multiplexed  onto  the  act^.^al  hardware 
processors  ly   the  inner  traffic  controller. 

^  virtual  processor  is  an  abstract  data  structure 
which  preserves  all  the  attributes  of  a  process  in  execution 
or  a  processor  (i.e.,  an  execution  point  and  ar  address 
space").  'Multiple  virtual  processors  rray  exist  for  a  single 
physical  processor.  The  Active  Process  Table  (APT)  is  the 
data  base  utilized  by  the  traffic  controller  to  contcl  and 
nana^-e  the  nul  t  iplexing-  of  processes  onto  virtual 
processors.  Figure  7  provides  an  exarple  of  the  the  APT. 

The  APT  is  d  fixed  sized  table  which  cor  tains  an 
entry  for  each  process  of  the  SASS  (the  processes  are 
created  at  systerr  p-enera tion)  .  Because  of  the  desifn 
decision   not   to   create   or  destroy  processes  after  system 
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.qienera  tion ,  the  initial  entries  into  the  APT  will  ce  active 
for  the  life  of  the  system.  The  index  into  the  \FT  is  the 
F?.OCESS_ID. 

The  traffic  controller  uses  the  PHIOPITT  field  of 
the  APT  to  determine  which  process  to  schedule  for  exe'^uticn 
on  each  virtual  pror-essor.  The  STATF  field  contains  that 
process'  current  state  (running,  blocked,  or  ready).  The  T'PPl 
(descriptor  base  re.a'ister'l  field  of  the  APT  pro-rides  the 
a'?dress  of  the  i^:"^'!  ima^^e  for  that  process.  The  N  ex  t  _?-Pady_AP 
field  is  a  DOinter  which  contains  the  index  of  the  ne^t 
process  which  is  in  the  ready  state. 

The  desii^n  simplification  choice  of  always  havin?'  a 
process  running-  on  the  virtual  processors,  introduced  the 
notion  of  an  idle  process  for  each  virtual  processor.  The 
idle  process  is  loaded  onto  a  virtual  processor  and  placed 
into  the  running  state  whenever  the  number  of  available 
virtual  processors  exceeds  the  number  of  ready  or  runnin^? 
processes  (excluding:  the  idle  process).  The  idle  process  is 
0-^  the  lowest  priority,  and  will  only  run  if  no  other 
process  can  be  loaded.  It  is  incapable  of  blocking-  itself, 
and  thus  must  always  be  in  either  the  running  or  r-^a-fy 
state. 

Vhen  a  virtual  processor  becomes  available.  the 
traffic  controller  will  be  invoked  to  schedule  the  highest 
priority  ready  process  which  nav  run  on  that  TDarticular 
virtual   processor.  If  no  process  is  ready,  the  Idle  r)rcce5S 
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is  scheduled.  The  Idle  process  provides  a  ne^ns  to  guarantee 
that  a  ready  process  will  always  te  foi:nd,  and  that  the 
Traffic  Controller  cannot  he  exited  without  schedulirs:  a 
process . 

5.   Inner  Traffic  Controller 

The  purpose  of  the  inner  traffic  controller  is  to 
provide  the  rrultiplexing  of  the  virtual  processors  onto  the 
actual  system  processorf s ) .  and  to  provide  the  kernel 
prinitives  for  inter-process  communication  within  the  1-cernel 
(Signal  and  'Tait).  In  the  SASS  desi^^n,  each  physical 
processor  has  a  fixed  set  of  virtual  C?^''s  that  it 
multiplexes.  The  primary  data  "base  utilized  hy  the  inner 
traffic  controller  is  the  Virtual  Processor  Tahle  ^V?T'. 
Figure  3  provides  an  example  of  the  VFT. 

The  V^T  is  indexed  ty  the  Vir tual_?rocesso r_I Z  .  The 
DBH ,  ?RI,  and  the  STATE  fields  are  used  in  tne  same  manner 
as  those  fields  in  the  APT.  The  Idie_Ilaf  simply  indicates 
that  the  i'^lo  process  is  loaded  on  that  virtual  rrocesscr. 
The  Preempt  flas-  indicates  that  a  virtual  ijreempt  int'=rrupt 
has  teen  directed  to  that  virtual  processor.  The 
?hys_Fro'"ess  or  is  a  fixed  field  that  indicates  which 
hardware  processor  that  virtual  processor  is  scheduled  to 
run  on.  The  Nex  t_?-eady_VF  is  a  Dointer  to  the  index  of  the 
next  ready  virtual  processor  in  the  VPT  for  this  C?^'. 

In  his  ori^unal  desie'ri.  Coleman  [3]  tasked  the  inner 
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traffic  controller  >.ith  the  rran'^rerent  of  t^e  hardware 
"^^emorv  Manaremert  Units  (which  contain  the  process'  address 
space  ard  its  attritutes)  and  the  MMU  software  ir^ares.  In 
the  present  design,  this  function  has  heen  assirred  to  the 
memory  mararer.  'vhen  the  inner  traffic  controller  unloads  a 
processor,  it  sin-ply  writes  the  ^'MU  into  the  f^MU  irraee  in 
order  to  save  the  se^^rrent  usage  information.  To  load  a 
DTOcess,  it  writes  the  ^''^MU  imasie  into  the  M'^U .  The  rerory 
manager  insures  that  th"  K"".^]  ima^ie  is  l^ept  current  "by 
ijpdatinp"  the  images  whenever  a  segment  is  swapped  in  or 
swapped  out  of  memory. 

Th=  kernel  synchronization  primitives  of  SIGNAl  and 
'''AIT  are  maintained  within  the  inner  traffic  controller. 
These  primitives  are  used  hy  virtual  processors  within  the 
'■cerrel  domain  to  synchronize  with  other  virtual  processors 
within  the  kernel  domain. 

r.   NON'-TI?TFI?UT^E  K??NoL 

The  SA.SS  non-d  i  s  trihnted  kernel  is  ccmpcsed  scl'=ly  cf 
the  memory  mana^-er  process.  ?ach  physical  processor  has 
associated  with  it,  its  own  dedicated  memory  manager 
process.  The  purpose  of  the  process  is  the  proper  and  secure 
management  of  the  main  memory  (both  local  and  plotal),  and 
secondary  s^ora^e.  The  actual  transfer  of  se?-ments  from  main 
memory  to  secondary  stcra^^e  and  vice-versa,  is  controlled  hy 
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i'le   rnppiorv  rara^pr  process.  The  prirnary  data   oase  utilized 

"by   the   process   is   the   Active   Seerent   Tahle.  Chapter  3 

provides  a  detailed  description  of   the   process'  functicrs 
and  data  tases. 
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III.         ^^SMORY    MANAGi:?.   PROCESS    DETAIISr    DESIGN 

A.       IN'TRODUCTION 

The  renory  rranas-er  is  responsitie  for  the  ranae-erent  of 

"both  main  memory  (local  and  elolal")  and   secondary   storage. 

It   is   a   ncn-dis trihuted   portion   of   the  kernel  wi^h  one 

memory  manae:er  process  existini?  per  physical  processor.   The 

memory   manager   is   tasked  (via  signal  and  wait)  to  Derform 

memory  management  functions  on  "behalf  of  other  processes   in 

the   system.   The  major  tasks  of  the  memory  manager  ar-^  :  1) 

the  allocation  and  deallocation  of  secondarv  stora^-e,  2)    the 

allocation  and  deallocation  of  ^looal  and  local   memory,   3) 

sefTrnent   transfer   from   local   to   global   memory  fand  vice 

versa),  and  4)  segment  transfer  frcm   secondary   stcrasre   to 

main  memory   fand   vice  versa).  There  are  ten  service  calls 

(via  sis;nal'*   which   tas"'':   th°   memory   manager   Process   tc 

perform  these  functions.  The  ten  service  calls  are: 

CREAT3:_ZNT?T 

■DEIETE_ENTPT 

ACTIVATE 

DEACTIVATE 

S'7AF_IN 

SWAP_OUT 

DEACTr7ATS_ALI 

MOVE_TO_GIO?AL 

^CVE_TC_LOCAL 

7PDATE 

Upon   completion   of  the  service  request,  the  memory  manager 

returns  The  results  of  the  operation  to  the  waiting   process 
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(via  5i<^r.al).  It  then  "bloc'-^s  itself  until  it  is  tasked  to 
perforrr  another  service.  The  hardware  conf  i.^ura  tion  manacled 
"by  the  n^errory  nandprer  process  i«  depicted  in  firure  9.  The 
shared  data  "bases  used  "by  ail  nemory  manasier  processes  are 
the  dotal  Active  ^egirent  Tatle  fG_AST),  the  Alia?  Tatle, 
the  Disk  Bit  Map,  and  the  C-lchal  Mercry  lit  i^ap .  The 
processor  local  data  "bases  used  "by  each  process  are  tne 
local  Active  Sea:pent  Ta"ble  (L_AST),  the  .^ercry  "^anarerent 
7nit  Inafiies  and  the  Local  l^erory  Bit  Map. 


P.     rEsic-r:  fara^^piters  ;.^J!)  riCisiONS 


Several  factors  were  identified  durin?^  the  desi^cn  rf  the 
nernory  manager  process  that  refined  the  initial  kernel 
desiien  of  Colendn[o]  .  The  two  areas  that  were  modified,  were 
the  manaf^e'i"ent  or"  the  "^MU  irra^es  and  the  management  of  core 
menorv.  3cth  of  these  functions  were  mancp^ed  outside  of  the 
memory  mana^-er  in  the  initial  desif-n.  The  inclusion  of  these 
functions  in  the  memory  ncnaf:-er  process  sif'nif  i  cantly 
improve^,  the  lne;ical  structure  of  the  overall  system  design. 
Additional  design  parameters  were  estal'lished  to  facilitate 
the  initial  implementation.  These  desi<^^n  parameters  reed  to 
he  addressed  before  the  detailed  desi^^-n  of  the  memory 
mana^T'er  process  is  presented. 

It  was  (decided  to  ^akf=  the  block/pa^ie  size  of  h'Cth  main 
memory   and   secondary   storage   equal   in  size.  This  was  to 
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Figure   9.   SASS  H/W  System  Overview. 
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simDlifv  the  rapping  al^orithri^  from  secondary  storaf^^e  tc 
rain  rreporj  (and  vice  versa).  In  the  initial  iesip-n  t^e 
hlock/pa<?'«=  size  was  set  tc  512  "bytes. 

The  sizp  of  the  pape  tatle  for  a  5e/?rrent  was  set  at  one 
page  fnon-Dcfed  paf:e  table).  This  was  to  sii'^plifv 
implementation,  and  had  a  direct  hearing  on  the  maxirrurr 
segnent  size  supported  in  the  r.erory  friana,?®?.  For  exarple,  a 
page  size  of  256  hytes  will  address  a  rrazirurr,  segrert  size 
of  32, "^6?  hytes  ,  while  a  ^a^e  size  of  512  bytes  will  address 
a  see-ment  si7e  of  131,272  "bytes. 

The  size  o^  the  alias  td"ble  was  set  to  one  ^a?e 
(non-paged  alias  table).  The  number  of  entries  that  the 
alias  ta"blo  will  support  is  limited  "by  the  size  cf  the  r)as;e. 
table  (viz.,  a  T)a^e  size  of  512  bytes  will  support  up  to  ''^6 
entries  in  the  Alias  Table). 

In  the  oria-inal  design,  the  main  memory  allocation  was 
external  to  the  memory  manager.  This  was  due  to  the 
partitioned  memory  manasiement  scheme  outlined  by  ?ar>s  [2] 
and  Colenan[?].  In  the  current  design,  all  address 
assignment  and  segment  transfer  are  managed  by  the  remory 
manager.  This  design  choice  enhanced  the  generality  of  the 
design,  and  provided  support  for  any  memory  management 
scheme  (either  in  the  mem-ory  manager  or  at  a  higher  level  of 
abstraction^.  However,  the  current  design  still  has  a 
maximum  core  constraint  for  each  process. 
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rvranic  memory  ncnagement  is  not  implemented  in  this 
d^sii^r.  Zach  process  is  allocated  a  fi7ed  siz^  of  physical 
core.  Fowever,  it  is  not  a  linear  allocation  of  physical 
memory.  The  design  supports  the  maximum  sharing  of  segments 
in  local  and  plolDal  memory.  All  se^rments  that  are  not 
sbared»  or  shared  and  do  not  violate  the  readers /writers 
prohlem  will  reside  in  lo^al  memory  to  eliminate  the  p-lolal 
hus  contention.  The  need  to  compact  the  memory  (tecai.^se  of 
f rammer  tat  ion )  should  he  minimal  in  this  design  due  to  the 
maximum  sharing  of  segments.  If  contiguous  memory  is  not 
available,  the  memory  manager  will  compact  main  memory. 
After  compaction,  the  memory  can  oe  allocated. 

Th°  d°sign  decision  to  represent  memi^ry  as  one 
contiguous  hlock  (not  partitioned)  was  made  to  support  a 
dynamic  memory  management  scheme.  Without  dynamic  memory 
mana,?ement,  the  process'  total  physical  memory  can  not 
exceed  the  systems  main  memory.  The  supervisor  knows  the 
size  of  the  segments  and  the  size  of  the  process'  virtual 
core,  therefore  it  can  manage  the  swap  in  and  swaD  out  to 
ensure  that  the  process'  virtual  rore  has  not  teen  exceeded. 

In  the  original  design,  the  user's  process  inner-traffic 
controller  maintained  the  software  images  of  the  memory 
management  unit.  This  design  required  the  memory  manager  to 
return  the  appro"oriate  memory  manaf^ement  data  (viz  .,  secernent 
location)   to   the   kernel   of   the  user's   urocess.  In  the 


current   design,   the   software   imasres 


the 


MU 
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neintained  ty  the  nen^ory  manager.  A  descriptor  "hase  pointer 
is  provided  for  the  irr.er-traf  f  i  c  controller  to  rultipl^:?: 
the  process  address  spaces.  The  f^r^'T  ira^e  data  tasp  does  not 
need  to  t^e  locked  ^to  prevent  race  conditions)  due  to  the 
fact  that  process  interrupts  are  masked  in  the  kernel.  Thus, 
if  the  rerrory  nana,£-er  (a  kernel  process)  is  running  then  no 
other  process  can  access  the  f^MU  irap-e. 

The  system  initialization  process  has  not  he«n  addressed 
to  date.  However,  this  design  has  made  some  assumptions 
ahout  the  initial  state  o^  the  system.  Since  the  memory 
manager  handles  the  transfer  of  segments  from  secondary 
storare  to  main  memory,  it  is  likely  to  le  one  of  the  first 
processes  created.  The  memory  maraf^er's  core  imar=  will 
consist  of  its  Dure  code  and  data  sections.  The  minimal 
initialization  of  the  memory  manager's  data  ■b.=  ses  are 
entries  for  the  system  root  and  the  suoervisor's  sef'ments  in 
the  G_AST  and  I_AST(s;,  and  the  ini  t  iali  zat  on  of  the  >^n^J 
ima.^es  with  the  kernel  segments.  The  current  design  does  not 
call  for  an  entry  in  the  G_AST  or  I_AST  for  the  kernel 
segments.  However,  when  system  generation  is  designed  this 
will  have  to  he  readdressed. 

The  original  [3]  memory  manager  data  bas=^s  have  heen 
refined  ly  this  thesis  to  facilitate  the  memory  management 
functions.  The  major  refinements  of  the  glotal  and  local 
active  se^^ment  tables  are  outlined  in  the  following  section. 


C.   TATA  PASES 

1 .   Glrtal  Active  Segment  Tat'le 

The  Global  Active  Segment  Tatle  (see  figure  le^  is  a 
system  wide,  shared  data  hase  used  "by  nemcry  rranager 
processes  to  rnana^e  all  active  se.crrients .  A  lock/unlock 
nechanisr  is  utilized  to  prevent  ar.y  race  conditions  from 
occurring.  The  si^nallin^'  process  locks  the  G_AST  "before  it 
signals  the  nenory  manager.  This  is  done  to  prevent  a  deadly 
err"brace  frorr  occurring'  "between  rnerrcry  ranae-er  processes,  and 
also  to  simplify  synchronization  "between  memory  managers. 
The  entire  G_A3T  is  locked  in  this  design  to  simplify  the 
iTiplementati on  (vice  lockinf  each  individual  entry 'i. 

The  G_AST  size  is  fixed  at  '"omoile  time.  The  size  of 
the  G_AST  is  the  prodi:ct  of  the  G_AST  record  size,  the 
maximum  num"ber  of  processes  and  the  number  of  authorized 
known  segments  per  process.  Although  the  G_AST  is  of  fixed 
size,  it  is  plausille  to  dynamically  manage  the  entries  as 
proposed  "bv  ?ichardson  and  0 'Connel  1  [ij  .  The  currert  memory 
manager  design  could  "be  extended  to  include  this  dynamic 
management . 

The  'Jnique_Id  field  is  a  unique  segment 
identification  num"fcer  in  the  G_AST.  This  field  is  four  bytes 
wide  and  will  provide  over  four  billion  id-i^ntificaticn 
num"bers,  A  desii?n  choice  was  made  not  to  manase  the 
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reallocation  of  the  uniqiie_ia'5.  Thrs  when  a  serrent  is 
delete*?  frcr  the  syster,  the  unique_id  is  not  reused. 

The  Global_Address  field  is  used  to  indicate  if  a 
segment  resides  in  global  or  local  nemory.  If  not  null,  it 
contains  the  plohal  nemory  lase  address  of  a  serrrent.  A  null 
entry  indicates  that  the  segment  might  he  in  local 
memory ( s ) . 

The  Proce5sors_I_ASTE_±i  field  is  used  as  a  connected 
processors  list.  The  field  is  an  array  stru'-ture.  indexed  hy 
?rocessor_Id .  It  identifies  which  I_AST  the  sernent  is 
active  in,  and  provides  the  index  into  each  of  these  tahles. 
The  design,  choice  of  maintaining  an  entry  in  the  I_AST  fcr 
all  legally  active  segments  implies  that  if  all  entries  in 
the  ?rocessor5_L_AST5_#  field  are  null,  the  sefme-t  is  not 
active  and  can  he  removed  from  the  C-_AST  (viz.,  no 
processors  are  connected). 

The  Flag_?its  fi^id  consists  of:  the  written  hit,  and 
the  writahle  tit.  The  written  hit  is  set  when  a  segment  is 
swapped  out.  c-^  memory,  and  the  "^M'f  image  indicates  that  it 
has  heen  written  into.  The  writatle  tit  is  set  during 
segment  loading  to  indicate  that  some  prc^ss  has  v/rite 
access  to  that  segment. 

If  an  active  segment  is  a  leaf,  the  G_AST2_i^_Farent 
field  provides  a  tack  pointer  to  the  C-_AST  index  of  its 
parent.  This  tack  pointer  to  the  parent  is  important  durinr 
the  creation  of  a  segment.   If   a   request   is   received   to 
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create  a  segment  *hich  has  a  leaf  seerent  as  its  parent, 
then  an  alias  tatle  has  to  te  created  for  that  parent.  Also, 
the  alias  tahle  of  the  parent's  parent  needs  to  'b<^  ijpdated 
to  reflect  the  existence  of  the  newly  created  alias  tatle 
(see  fip^ure  11).  The  indirect  pointer  shown  is  the  t&rk 
pointer  to  the  narent  via  the  G_A?T. 

The  No_Ac  tivp_In_N'emory  field  is  a  count  of  the 
nurrlDer  of  processes  that  have  the  se<?rr:ent  in  ^lohal  rerorv. 
It  is  used  during  svap  out  to  determine  if  the  se<?Tent  can 
"be  removed  -^rom  ^lotal  merrory. 

The  Mo_Act ive_rependents  field  is  a  count  of  the 
numher  of  active  leaf  segrrents  that  are  dependent  on  this 
entry  fviz.»  require  that  this  segment  remain  in  the  G_AST}. 
^ach  time  a  process  activates  or  deactivates  a  dependent 
segment  this  field  is  incremented  or  decremented. 

The  Size  field  is  tne  size  of  the  se,sment  in  tytes. 
•^he  ?a^e_Talle_locaticn  field  is  the  disk  location  of  the 
page  tahle  for  a  segment,  and  the  Alias_Tahle_Io ca t i on  field 
is  the  disk  location  of  the  alias  tahle  for  the  segment.  The 
Alias_Tahlp  field  can  "be  null  to  indicate  that  no  alias 
ta"ble  exists  for  the  sep-ment. 

The  last  three  fields  are  used  in  the  management  of 
eventccunts  and  sequencers  [4].  The  Sequencer  :^ield  is  used 
to  issue  a  service  numler  for  a  se^-ment.  The  Instance_l 
field  and  Instance_2  field  are  eventcounts  (i.e.,  are  used 
to  indicate  the  next  num"ber  of  occurances  of  some  event). 
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2.  Local   Active   Segment    Ta"ble 

The  local  Active  Segment  Talle  (see  figure  12)  is  a 
processor  local  data  "base.  The  I_AST  contains  the 
characteristics  (viz.,  segment  number,  access)  of  each 
locally  active  segment.  An  entry  exists  for  ea'^h  segment 
that  is  active  in  a  pT-ocess  "loaded"  on  this  CPU  and  in 
local  memory.  The  first  field  of  the  L_AST  contains  th« 
memory  address  of  the  segment.  If  the  segment  is  not  in 
memory,  this  field  is  used  to  indicate  whether  the  L_AST 
entry  is  available  or  active.  The  ?egment_No/Access  field  is 
a  comhinaticn  of  segment  numher  and  authorized  ac^^^ss.  It  is 
an  array  of  records  data  structure  that  is  inde^ied  ty  D'PP_s-. 
The  first  record  element  (viz., most  significant  hit")  is  used 
to  indicate  the  access  (read  or  read/write)  Permitted  to 
that  segment.  The  second  record  element  (viz.,  the  next 
seven  hits)  is  used  to  indicate  the  segment  number.  A  null 
segment  number  indicates  that  the  pro'^ess  dees  not  have  the 
segment  active. 

3.  Alias  Table 

The  alias  table  (see  figure  13^  is  a  memory  manager 
data  base  whi'^h  is  associated  with  each  ron  Ipaf  segment  in 
the  kernel.  An  aliasing  S'^heme  is  used  to  prevent  passing 
systemvide  information  (unique_id.}  out  of  the  ^^cernel  . 
Segments  can  only  be  created  through  a   mentor   segment   and 
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entry  niimter  into  the  mentor's  alias  tatle.  '^hen  a  serpent 
is  created,  an  entry  rust  te  made  in  its  nertor  segrent's 
alias  tatle.  Thus  the  mentor  segment  rust  "be  knovn  tefore 
that  seeiFent  ran  "be  created. 

The  alias  tahle  consists  of  a  header  and  an  array 
structure  of  entries.  The  header  has  two  "pointers"  ^vi?., 
disk  addresses!,  one  that  links  the  alias  tahle  to  its 
associated  sernent  and  one  that  links  the  alias  talle  to  the 
nentor  segr«^nt's  alias  tahle.  The  header  is  provided  to 
support  the  re -const  ruction  of  the  file  systeir  after  a 
system  crash  due  to  device  I/O  errors.  It  is  not  used  at  all 
dnrinp"  normal  operations.  Each  entry  in  the  array  structure 
consists  of  five  fields  for  identifying  the  created 
segments.  The  "'Jnique_Id  field  -"ontains  tne  unique 
identification  numter  for  the  se<rnent.  The  Size  field  is 
used   to   r°rord   the   size   of  the  segm'ent.  The  Class  field 


contains   the   appropriate   securitv   access   class 


the 


S'^^ment  .  The  Pa?e_Ta"ble_Locat  ion  field  has  the  disk  address 
of  the  pape  tahle.  A  null  entry  indicates  a  zero-lenrth 
segment;.  The  i^.l  ias_Ta"*"l  e_Loca  t  ion  field  has  the  disk  address 
of  the  alias  tahle  for  the  segment.  A  null  entry  indicates 
that  the  seigment  is  a  leaf  segment. 


4.   i^erory  "^ana^-enent  Unit  Imare 


The  Memory  ^^anagement  Unit  Ima^re   (MMU_In-age)   is   a 
processor  local  data  tase.  It  is  an  array  structure  that  is 
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irdexed  "by  the  I3?._i^.  Each  MMU_Ira^e  (see  fisrure  14.) 
includes  a  software  representation  of  the  se^^rent  descriptor 
registers  (SDR)  "or  the  hardware  MMU  [12].  This  is  in 
exactly  the  format  used  ty  the  special  I/O  instructions  for 
1  oadins'/unloadini^  the  r^M'J  hardware.  The  SD?.  rcrtairs  the^ 
rase_Address ,  limit  and  Attritute  fields  for  each  loaded 
segment  in  the  process'  address  snace.  The  Pase_Address 
field  contains  the  "base  address  of  the  se^'ner.ts  in  memory 
(local  or  ?-lotal).  The  Limit  field  is  the  nurher  of  hloc'/.s 
of  contiguous  storare  for  each  segment  (zero  indicates  one 
"block).  The  Attrihute  field  contains  ei^^ht  fla^s.  Five  fla^s 
are  used  for  protecting  the  segment  against  certain  tvpes  of 
a-'cess,  two  encode  the  tyiDe  of  accesses  made  to  the  segment 
(read/write"),  and  one  indicates  the  special  structure  of  the 
segment  [1?].  Jiye  of  the  ei^^ht  fla^-s  in  the  attritute  field 
are   used   "by   the   memory  manaprer.   The   "system  only"  and 


'execute  onlv"  flars  are  used  to  protect   the   code 


the 


>errel  from  malicious  or  unintentional  modifications.  The 
"read  only"  fla^  is  used  to  control  the  read  or  write  access 
to  a  segment.  The  "chan^^e"  flag  is  used  to  indicate  that  the 
segment  has  teen  written  into,  and  the  "C?U-inhihi  t "  flap-  is 
used  to  indicate  that  the  segment  is  not  in  memory. 

The  last  two  fields  of  the  ^^MU_Ima?e  are  the 
Plock_'^sed  field  and  the  ^'aximum_Availahle_'^lcc^-:s  field. 
These  two  fields  are  used  in  the  man^ement  of  ea'^h  process' 
virtual  core  and  are  not  associated  with  tne  hardware  yMJ. 
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DSR   #. 
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Figure   14.      r^emory   ^^anagement   Unit    Image 
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5.  Merrory  Alio  cation/Deall  ocat  i  on  5it  ^aps 

All  of  the  memory  allocat ion /dealiocatior  bit  maps 
(see  fif-'ure  15)  are  "basically  the  sane  structure.  Secondary 
storage,  global  memory  and  local  memory  are  manap'-ed  "bv 
memory  "bit  rraDS.  The  risk_Pit_Map  is  a  ^lo"bal  resource  that 
is  protected  from  race  conditions  via  the  lockinr  convention 
for  the  G_A?T.  Tach  bit  in  the  "bit  map  is  associated  wi*:h  a 
block  0^  secondary  storage.  A  zero  indicates  a  free  blocir  of 
storag:p  whil^  a  one  indicates  an  allocated  block  of  storage. 
The  Glcbal_f''emory_Ii  t_^'ap  is  used  to  manage  global  memory. 
It  is  a  shared  resource  that  is  protected  from  rare 
conditions  by  the  lockins-  of  the  G_AS'^.  The 
Iocal_N*emory_Ei  t_Map  is  the  same  structure  as  tne 
C-lobal_^emory_P it_Map  and  is  used  to  manage  local  memory. 
The  Iocal_Memory_Pi  t_N'ap  is  not  locked  since  it  is  not  a 
shared  resource  between  memory  managers. 

E.   SASIC  ?UMCTIO\'S 


The  detailed  source  code  for  the  basic  functions  and 
main  line  of  the  memory  manager  are  presented  in  appendices 
A  and  P.  Appendix  A  lists  the  Drocedures  whicn  are  coded  in 
P1Z/?YS»  while  Appendix  I  lists  the  lower  level  hardware 
dependent  procedures  which  ar©  coded  in  PIZ/ASM. 

PIZ/SYS  is  a  hif'h  level  modular  structured  lanrua^e 
which   produces   a   machine-independent   Z-ccde   similar   to 


Memory     Bit      Map 
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•  •  •  • 

Figure     15.      Memory   Allocation/Deallocation  Map. 
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PASCAL'S  P-code.  The  translator  from  Z-'^ode  tc  Z-t000 
Tiachine  code  is  currently  under  developnent  at  ZIIOG  Inc., 
thus  the  PIZ/SYS  module  could  not  he  compiled  on  the  Z9eP0 
[13].  PIZ/ASM  is  a  s?/mtolic  assemhlv  larguage  that  is  used 
to  program  the  Z-a002.  The  assemhier  supports  Structured 
programming  and  produces  a  relocatable  Z-600Z  olject  module. 

In  the  discussion  of  the  memory  manai^er  design,  a 
pseudo-code  similar  to  PIZ/SYS  is  utilized.  The  rationale 
for  using  this  pseudo-code  was  to  provide  a  summary  of  the 
memory  manager  source  code,  and  to  facilitate  the 
presentation  of    this  design. 

It  is  assumed  that  the  memory  manager  is  initialized 
into  the  ready  state  at  system  generation  (as  previously 
mentioned).  When  the  memory  manager  is  initially  placed  into 
the  running  state,  it  will  block  itself  (via  a  call  to  the 
kernel  primitive  V/ait).  Wait  will  return  a  message  from  a 
signalling  process.  This  message  is  interpreted  by  the 
memory  manager  to  determine  the  requested  function  and  its 
required  argruments.  The  function  code  is  used  to  enter  a 
case  statement,  which  directs  the  request  to  the  appropriate 
memory  manager  procedure. 

When  the  requested  action  is  completed,  the  memory 
manager  returns  a  success  code  (and  any  additional  required 
data)  to  the  sip-nallins-  process  via  a  call  to  the  kernel 
primitive  Signal.  This  call  will  awaken  the  process  which 
requested  the  action  to  be  taken,   and   place   the   returned 
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messa,?e  into  that  process'  r^essa^'e  queue.  Vhen  that  action 
is  completed,  the  memory  manager  will  return  to  the  top  of 
the  loop  structure  and  block  itself  to  wait  for  the  the  next 
request.  The  main  line  pseudo-code  of  the  memory  manager 
process  is  displayed  in  figure  16. 

1.   Create  an  Alias  Tahle  Entry 

Create_Entry  is  invoked  when  a  user  desires  to 
create  a  segment.  A  se^-ment  is  created  hy  allocating? 
secondary  storage,  and  "by  making  an  entry  (nnique_id, 
secondary  stora^^e  location,  size,  classification)  into  it's 
mentor  see-ment's  alias  tahle.  This  implies  that  the  mentor 
segment  must  have  an  alias  table  associated  with  it,  and 
that  the  mentor  segment  must  be  active  in  order  to  obtain 
the  secondary  storage  location  of  the  alias  table. 

The  mentor  segment  can  be  in  one  of  two  states.  It 
may  have  children  (viz.,  have  an  alias  table"^,  or  it  may  be 
a  leaf  segment  (viz.,  not  have  an  alias  table).  If  the 
mentor  segment  has  children,  it  has  an  alias  table  and  this 
alias  table  can  be  read  into  core,  secondary  storage  can  be 
allocated,  and  the  data  can  be  entered  into  the  alias  table. 
If  the  mentor  segment  is  a  leaf,  an  alias  table  must  be 
created  for  that  segment  before  it  (the  alias  table)  can  be 
read  into  core  and  data  entered  into  it  (see  figure  11  ">  . 

The  pseudo-code  for  CR2AT3^_SNT?.Y  FR'^CFLUHE  is 
presented  in  figure  17.,  The  arguments  passed  to  Creatp_rntry 
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ENTRY 

INITIALIZS_P?.0C2SSCR_L0CAL_VAP.IAPL5S 
DO 

!      CHECK_IF_MSG_OUSUE_SMFTY      ! 

YF_ir,    MSG    :=   WAIT 

FUNCTION,    AEGUyEMTS    :=   VALIDATE.MSG    (^^SG^ 

IF      FUNCTION 

CASE      CREATE_ENTR^      THEN 

SUCCESS_COrE    :=   CREATE    ENTRY    (ARGUMENTS) 
CASS      DEIETE_ENTRY      THEN 

SUCCESS_CODE    :=   DELETE_ENTRY    (ARGUMENTS) 
CASE      ACTIVATE      THEN 

SlTCCES£_COrE    :=   ACTIVATE    (ARGUMENTS) 
CASE      DEACTIVATE      THEN 

SUCCESS_COrE    :=   DEACTIVATE    (ARGUMENTS) 
CASE      SWAP_IN      THEN 

SUCCESS    CODS    :=   S,'/A?_IN    (ARGUYiENTS) 
CASE      SWA?_OUT    THEN 

SUCCESS_CODE    :=   SVAp_OUT    (ARGUMENTS) 
CASE      DEACTIVATE   ALL      THEN 

SUCCESS_CODE~:=   DEACTIVATE_AIL    (  AFG't?^tntS  ^ 
CASS      M0VS_T0_GL03AL      THEN 

SUCCESS_COrE    :=    MOVE   TO_GLORAL    (ARGUMENTS) 
CASE      MOVE_TO_ICCAI      TEEN 

SUCCESS_CODE    :=   MOVE_T0_LOCAL    (ARGUMENTS) 
CASE      UPDATE      THEN 

SUCCESS_CODE    : =   UP! ATE    (ARGUMENTS^ 
FI 

SIGNAL    (VP_ID,    SUCCESS_CODE,    ARGUMENTS) 
CD 
END      MEMORY_MANAGER_PIZ/SYS      MODULE 


Fie*ure      16.      Memory  ^'dnager    Mainline    Code 
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CEEAT5_:3NTRY    FROCECURE    (?AR_INDEX       //ORD,    ENTRT_#      WORD, 

SIZE         WGFI,    CLASS  lYTE) 

HET'JRNS    (S'JCCESS_COrE      BYTE) 

LOCAL      PLKS      WORD,    FAr-?_TA£LS_LOC      WCRi: 

ENTRY 

IE      ALIAS_TAFLE_DOES_NOT_EXIST         THEN 
STTCCESS_CODE    :=    CEEATE_ALIA^_TA1:  LE 
IF      S'JCCESS_COI)E   ^>    VALID      THEN      RETUR.\' 
FI 

FI 

ELKS  :=  CALCULATE_NC_FLKS_REQ  fSiZE) 

SlTCCESS_CODE  :=  READ_ALI AS_TABLE  ( 

G_AST[FAH_INrSX]  .ALlAS_TArLE  LOC) 

IF   S7CCESS_C0EE   <>   VALID   THEN   RETURN 

FI 

SUCCESS_COrE  :=  CHECK_rUF_ENTRY   !  in  alias  tatle  ! 

IF   SUCCESS_CODE   ^>   VALID    THEN    BETURN 

FI 

SUCCESS_CCrE,  FACE  TAELE_LOC  :=  / LLOC_SEC_STORAaE  ( BLKS ^ 

IF   S7CCESS_C0DE  <>      VALID    THEN    RETURN 

FI 

r?DATE_ALIAS_TAPLE(ENTRY_#,  SIZE,  CLASS,  FAr.E_TAFLE_LCC '■ 

SUCCESS_COLE  :=  WRITS  ALIAS  TABLE  ( 

"■g_aotTpar_index]  .ALIAS_TABLE_L0C; 

IF  SncCESS_CCDE  <>   VALID   THEN    RETURN 

ELSE   SUCCSSS_CODE  :=  SEG_CREAT^D 

FI 

END    CREATE    ENTRY 


Fif-ure    17.      Create   Entry    Fseudc-code 
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are  the  index  into  the  G_AST  for  the  n^entor  segment,  the 
entry  number  into  its  alias  table,  the  size  of  the  se,s;ment 
to  be  created,  and  the  security  access  class  of  that 
segment.  The  return  parameter  is  a  success  code,  which  would 
be  "5e/?_created"  for  a  successful  segment  creation. 

When  invoked,  Create_2ntry  will  determine  which 
state  the  mentor  sediment  is  in  (viz.,  if  it  has  an  alias 
table).  If  an  alias  table  does  not  exist  for  the  mentor 
segment,  one  is  created  and  the  alias  table  of  the  mentor 
segment's  parent  is  updated.  The  alias  table  is  read  into 
core  and  a  duplicate  entry  cneck  is  made.  If  no  duplicate 
entry  exists,  the  segment  size  is  converted  from  bytes  to 
blocks,  and  the  secondary  storage  is  allocated  for  non-zero 
sized  segments.  The  appropriate  data  is  entered  into  the 
alias  table  and  the  alias  table  is  then  written  back  to 
secondary  storage. 

2.   Delete  an  Alias  Table  Entry 

Delete_Entry  is  invoked  when  a  user  desires  to 
delete  a  segment.  A  segment  is  deleted  by  deallocating 
secondary  storage,  and  by  removing  the  appropriate  entry 
from  the  alias  table  of  its  mentor  segment  (the  reverse 
logic  of  Create_"n try ) .  This  implies  tnat  the  mentor  segment 
must  be  active  at  the  time  of  deletion.  There  are  three 
conditions  that  can  be  encountered  during  the  deletion  of  a 
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segment:  the  segment  to  be  deleted  may  te  an  inactive  leaf 
segment,  an  active  leaf  segment,  or  a  mentor  segment. 

If  the  segment  to  be  deleted  is  an  inactive  leaf 
segment  (viz.,  has  "been  swapped  out  of  core,  and  does  not 
have  an  entry  in  the  G_A3T),  the  secondary  storage  can  he 
deallocated  and  the  entry  deleted  from  the  mentor  segment's 
alias  table.  If  the  segment  is  an  active  leaf  segment,  the 
segment  must  first  be  swapped  out  of  core  and  deactivated 
before  it  can  be  deleted.  This  entails  si^-nallinp-  the  memory 
manager  of  each  processor,  in  which  the  segment  is  active, 
to  swap  out  and  deactivate  the  segment. 

If  the  segment  to  be  deleted  is  a  mentor  segment,  an 
alias  table  exists  for  that  segment  .  If  the  alias  table  is 
empty,  the  secondary  storage  for  the  alias  table  and  the 
segment  car  be  deallocated,  and  the  entry  for  the  deleted 
segment  can  be  removed  from  its  mentor's  alias  table.  If  the 
alias  table  contains  any  entries,  the  segment  cannct  be 
deleted  because  these  entries  would  be  lost.  If  this 
condition  is  encountered  a  success  code  cf 
"leaf _segment_exis ts "  is  returned  to  the  process  which 
requested  to  delete  the  entry.  Due  to  a  confinement  problem 
in  "upgraded"  segments,  this  3uccess_code  cannot  always  be 
passed  outside  of  the  kernel.  This  implies  that  the  segment 
manager  must  strictly  prohibit  deletion  of  a  segment  with  an 
access  class  not  equal  to  that  of  the  process. 
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The  pseudo-code  for  rr:LSTr_?NTRY_?RCCErUF.I  i? 
presented  in  figure  1£.  The  parameters  that  are  passed  to 
this  procedure  are  the  parent's  index  into  the  G_AST  and  the 
entry  numher  into  the  parent's  alias  tahle  of  the  segment  to 
"be  deleted.  The  al  ias_tahle_loc  field  is  checked  to 
determine  the  state  of  the  mentor  segment  (either  a  leaf  or 
a  node),  and  the  appropriate  action  is  then  taken.  A  success 
code  is  returned  to  indicate  the  results  of  this  procedure. 

3.   Activate  a  Segment 


Activate  is  invoked  when  a  user  desires  to  make  a 
segment  known  hy  adding  a  segment  to  his  address  space.  A 
segment  is  activated  hy  making  an  entry  into  the  I_A?T  for 
that  processor,  and  the  G_AST.  The  activated  segment  could 
he  in  one  of  three  states;  it  could  have  previously  teen 
activated  hy  another  process  and  hdve  a  current  entry  in 
hoth  the  G_AST  and  L_AST,  it  could  have  previously  heen 
activated  hy  another  process  on  a  different  processor  and 
have  an  entry  in  the  G_AST  hut  not  the  I_AST,  or  it  could  je 
inactive  and  have  an  entry  in  neither  the  G_AST  rcr  the 
I_AST. 

If  the  segment  to  he  activat-^d  already  has  entries 
in  hoth  the  L_AST  and  G_A3T,  these  entries  need  only  he 
updated  to  indicate  that  another  process  has  activated  the 
5e,?ment.  The  segment  numher  is  entered  into  the 
Segment_Wo/Access_Auth   field  of   the   L_AST,   and   if   the 


EELETE_FMTKY  FROCErUHE  (  ?AP_INE?X   'a'CRT,  ENTRY_#   '.vOHr  ) 
RETURNS  (SaCCESS_COrE   JETTE) 
lOCAI   ^AP_INrEX   /^CRC 
ENTRY 
!  Checlc  if  the  passed  rrentor  segment  has  an  alias  table.  ! 
IF  G_A?T[FAP_iNEEX] .ALlAS_TArIE_lOC  <>  NULL 
SUCCESS_COrE  :=  REaL_ALIAS_T ABLE  ( 

G  AST[?AR_INrEX] .ALIAS  TAELE_LOC) 
ELSE 

SUCCESS_CODE  :=  NO_CHILD_TO_I;ELETE 
EI 

IF   SUCCESS_CODE   <>   VALIL     TEEN    RETURN 
FI 
!  Teternine  if  segment  has  children  in  alias  ta'ble  ! 
IF   AIIAS_TAxIE  NOT_EMPTY    THEN 

S:JC^ESS_CODE  :=  LEAF_SEGMEMT_EX  ISTS 
RETURN     !  Telption  will  delete  children  ! 
ELSE 
!  Search  G_aST  with  UNIOUE_ID  to  verify  segment  inactive  ! 
IE   ACTIVE_IN_r_AST    THEN 

'  Check  if  active  in  AST  ! 
IF   ACTIVE_IN_L_AST   THEN 

ESACTIVATE_ALL  (G_AST_INDSX ,  I_AST_INDEX) 
FI 
?  Check  G_AST  to  verify  segment  inactive  in  other  I_AST's  ! 
IF   ACTIVE_IN_OTHER_L_AST   THEN 

SIGNAL_TO_EEACTIVATE_ALL  ( G_AST_I NIEX ) 
FI 
FI 

F?EE_SEC_STORAGE_OE_SSG_r^_AIIAS  IF_EXISTS 
ESIETE_AIIAS_TABLE_ENTPY 
FI 

EELETE_AIIAS_TAiLE  ENTRY 
S'JCCESS_CODE  :=  aRITS_ALIA^_TABI  E  ( 

G_AST[FAR_INEEX] . ALIAS_TAiLE_IOC ) 
IF   SncCESS_COEE  =  VALIE   THEN 

?UCCESS_COEE  :=  SEG_DEISTEL 
FI 
ENE  EEIETE  ENTRY 


Figure  16.   Eelete  Entry  Pseudo-code. 


segment  is  a  leaf,  its  mentor's  N'c_Active_Deper)dents  field 
in  the  G_AST  is  incremented.  In  this  design,  the  G_AST  is 
always  searched  to  determine  if  the  se^^ment  has  "been 
previously  activated  by  another  process. 

If  the  segment  to  te  activated  has  an  entry  in  the 
G_iiST  but  not  the  L_AST,  an  entry  r^us  t  be  made  in  the  L_AST 
and  the  G_AST  must  be  updated.  The  L_AST  is  searched  to 
determine  an  available  index.  The  segment  number  is  entered 
into  the  L_AST,  and  the  index  number  is  entered  into  the 
G_AST  Processors_L_AST5:_#  field.  If  the  segment  to  be 
activated  is  a  leaf  segment,  its  mentor's 
N'o_Acti ve_Dependents  field  in  the  G_A3T  is  incremented. 

If  the  activated  segment  does  not  have  an  entry  in 
either  the  C-_AST  or  L_AST,  an  entry  must  be  made  in  both. 
The  G_AST  is  searched  to  find  an  available  index,  and  the 
entry  is  rr-ade.  The  I_AST  is  then  searched  to  find  an 
available  index,  and  the  entry  is  made.  The  I_AST  index  is 
then  entered  into  the  G_AST  Frocessors_L_A3TZ_^  field.  If 
the  activated  segment  is  a  leaf,  the  N'o_Active_Iependent  s 
field  of  its  mentor's  G_AST  entry  is  incremented. 

The  pseudo-code  for  ACTIVATE  FKGCErUFE  is  presented 
in  figure  19.  The  parameters  that  arp  passed  are  the  D1V._I^ 
of  the  signalling  process,  the  mentor  segment's  index  into 
the  G_AST,  the  alias  table  entry  number,  and  the  segment 
number  of  the  activated  segment.  The  mentor  se/?ment  is 
always   checked   to   determine  if  it  has  an  associated  alias 
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\CTIVAT?:      PP.OCEP^TRE    (rrR_#      iYTE,    PA?._IMD?:X      WOPT, 

ENTRY_#      V/CED,    SI:GK5,MT_N0      BYTE) 
HETTTPNS    (SUCCESS_CODE      lYTE,    HFT_C-_AST_HANrLE      HANDLE, 

CI ASS      3YTE,    SIZE      MOID) 
LOCAL        C_INDEX      ^'/ORD,      L_INDEX      WORD 
EMTRY 
!    Verify    that    Dassed    segment    is    a   mentor    segment    ! 
IE   a_AST  [PArIiNTEX]  .ALIAS_TAEIE_LOC    <>   0    THEN 
SUCCESS_COLE    :=   READ.ALI AS_TAEIE    ( 

G_AST[PAR_INEEXJ  . ALIAS_TARIS_IOC ) 
ELSE 

SUCCESS_COrE    :=   AIIAS_DOES    NOT    EXIST 
EI 

IE      SUCCESS_COrE    ^>      VALID      THEN         RETURN 
FI 
!    Check   G_AST    to    determine    if    active    ! 

SUCCESS_CODE, INDEX    :=    SSARCH_G_AST    (UNI0UE_ID; 
IE    STTCCESS_COrE    =    FOUND    THEN 

IE      SEGr^ENT    IN_L_AST      THEN 

UPDATS_L    AST    (SEG^SNT_NO) 
ELSE 

MAKE_L_AST_ENTRY    (DBR   #,    SEGMENT_NO) 

UFDATS_G    AST    (L_INDEXT 

IF    G_ASTTINDEX] .AIIAS_TA£LF_L0C    =    NULL    THEN 

G_AST[PAR_INDEXJ  .NO_DEPENDENTS_ACTIVE    -=   1 
FI 
FI 
ELSE 

MATE_G_AST_ENTRY    (ENTRY_#) 
^AKE_L_A?T_ENTFY    (PAR_INrEX.    ENTRY_#^ 
FI 

S'JCCESS_CODE  :=  SSG  ACTIVATED 
END  ACTIVATE 


Fip-ure  19.   Activate  Pseudo-code 
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table.  If  it  does  not,  the  success  code  of 
"alias_does_not_exist"  is  returned.  If  the  alias  tatle  does 
exist,  it  is  read  into  core  and  the  entry  number  is  used  as 
an  index  to  obtain  the  activated  se^-ment's  unique_id.  The 
G_AST  is  then  searched  to  determine  if  the  sep-ment  has 
already  been  activated.  If  the  unique_id  is  found,  the  u_AST 
is  updated  and  the  I_AST  is  either  updated  or  an  entry  is 
made  (dependir,?  on  whether  an  entry  existed  or  not).  If  the 
unique_id  of  the  segment  was  not  found  during  the  search  of 
the  G_A.ST,  an  entry  must  be  made  in  both  the  G_a"T  and 
L_AST.  Activate  returns  the  activated  segment's 
classification,  size,  and  handle  to  the  si^nallint  process. 

4.   Deactivate  a  Segment 

Deactivate  is  invoked  when  a  user  desires  to  remove 
a  segment  from  his  address  space.  To  deactivate  a  segment, 
the  memory  manager  either  removes  or  updates  an  entry  in 
both  the  L_AST  and  G_AST.  Deactivate  uses  the  reverse  logic 
of  activate.  Once  a  segment  is  deactivated,  it  can  only  be 
reactivated  via  its  mentor's  alias  table  as  discussed  in 
activate.  If  a  process  requests  to  deactivate  a  segrr-ent 
which  has  not  "been  swapped  out  of  the  process'  virtual  core, 
the  memory  manager  swaps  the  segment  out  and  updates  the  MMU 
image  before  the  segment  is  deactivated.  The  segment  to  be 
deactivated  cculd  be  in  one  of  thrpe  states?  more  than  one 
process   could   concurrently   hold  the  segment  active  in  the 
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I_AST,  the  se^mert  could  be  held  active  "by  one  process  in 
the  I_AST  and  rtiore  than  one  in  the  C-_AST,  the  sepr^ent  could 
"be  held  active  "by  onlv  one  process  in  "both  the  I_AST  and  the 
G_AST. 

Deactivation  of  leaf  segments  and  mentor  scfrments 
are  handled  differently.  If  the  segment  is  a  mertoT'  se&rrent 
and  has  active  dependents,  it  cannot  "be  removed  from  the 
G_AST  (even  though  no  process  currently  nas  that  segment 
active).  This  is  "based  on  the  desi<?n  decision  which  requires 
that  the  mentor  of  all  active  leaf  segments  remain  in  the 
G_AST  to  allow  access  to  its  alias  tahle.  The  mentor's  alias 
table  must  he  accessible  when  an  alias  table  is  created  for 
a  dependent  leaf  segment.  If  a  leaf  segment  is  deactivated, 
the  iMo_Active_Lependents  field  of  its  mentor's  G_^ST  entry 
is  decremented.  A  mentor  segment  can  only  be  removed  from 
the  G_AST  if  no  process  holds  it  active,  and  it  ha?  no 
active  dependents. 

If  more  than  one  process  concurrently  hold  a  seener.t 
active  in  the  I_AST,  and  one  of  them  sis-nals  to  deactivate 
that  segment,  the  entry  in  the  I_AST  is  updated.  This  is 
accomplished  by  nullin?-  out  the  Segment_No/Acce5S_.Auth  field 
of  the  I_AST  for  the  appropriate  process.  If  required,  the 
No_Active_Dependen  ts  field  of  its  mentor  sef'ment's  n_AST 
entry  is  decremented. 
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If  only  one  process  holds  the  segment  active  in  the 
I_AST,  and  that  Process  sie:nals  to  deactivate  the  se-prrent  , 
the  L_A.ST  entrv  for  that  segtrent  is  reroved.  The 
Frocessors_I_ASTE_ir  is  updated  and  checked  to  deterrrine  if 
there  are  other  connected  processors.  If  there  are  no  ether 
connected  processors  and  the  segment  has  no  active 
dependents,  the  segment  is  removed  from  the  G_AST.  If  there 
are  other  connected  processors,  the  G_A3T  is  updated.  If  the 
deactivated  segment  is  a  leaf,  the  mentor  segment's 
No_Acti ve_rependents  field  in  the  G_AST  is  decrerr:ented . 

The  pseudo-code  for  DEACTIVATE  FROCZLIJKE  is 
presented  in  fis-ure  22,  The  parameters  that  are  passed  to 
the  memory  manager  are  the  DBH_f?  of  the  signalling  process, 
and  the  index  into  the  G_AST  for  the  segment  to  he 
deactivated.  The  procedure  first  updates  the  L_AST,  and  then 
removes  the  entry  if  no  local  pro-^ess  holds  the  segment 
active.  The  G_AST  is  then  updated,  and  its  mentor  segment  is 
checked  (if  the  deactivated  se-p-ment  was  a  leaf),  to 
determine  if  it  can  te  removed.  If  no  processe'=  currently 
hold  the  segment  active,  and  it  has  no  active  dppendents, 
the  segment  is  removed  from  the  G_AST. 

5.   SwaD  a  Segment  In 

SWAP_IM  is  invoked  when  a  user  desires  to  swa-o  a 
segment  into  main  memory  (glohal  or  local)  from  seconr'ary 
storage.  A  segment  is  swapped  into  main  memory  ty   obtaining 
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D5ACTIVAT 

P.FTTTR 
IOC  A  I 

ENTRY 

Check 

IF   G_ 
J 

I 


f 


END 


F 
FI 

R  e  m  0  V 
L_AST 
CHECK 
IF      N 

L 
FI 

Check 
IF   G_ 

Deter 
C 

FI 
Deter 

CHECK 
S^^CCE 
DSACT 


E      PHOCED 
NS    (S'JCCE 
INDEX 

if  s e srn e 
AST  [INDEX 
Check  MMU 
F      IN_LOC 

saccEs 

I 

e  process 
[L_INrEX] 
_IF_flCTIV 
07_ACTIVE 
_AST[I_IN 

if  delet 
AS-^EIMDEX 
_AST[PAR_ 
mine  i  f  p 
HECK_FOR_ 

nine  i f  d 
_FOR_REr^O 
S?_COrF  : 
IV  ATE 


UHE    (DBR_#      EITS,    PAS_INDEX      WORD) 
SS_CODE      BYTE) 
WORD 

nt    is    in    core    ! 

]  .N^_ACTIVS_IN_^EMORY    <>    0    THEN 

iiras-e    to    deterrnine    if    in    local   remcry    ! 
AL_MF^ORY      THEN 
S_CODE    :=   OUT    (DPR_#,    INDEX) 


se^nent_no    entry   in   L_AST    ! 
.SEG^^ENT_NO/ACCESS_AUTH[DBR_#J    =    Q 
E_IN_I._A3T    (l_AS'^_INrEX) 
_IN    I_AST      THEN 
DEXl.MEy!CRY_ADDR    :=    AVAIIAELE 

ed   segment   was    a    leaf    ! 

J .G_ASTE_^_PAR  <>  0   THEN 

INDEX] .N0_LFFENDENTS_ACTIVE  -=  1 

arent  can  be  removed  ! 

REMOVAL  (PAR_INDSX) 

eactivated  see;ment  can  ce  removed  ! 
7AL  (INDEX) 

=  SEC  DEACTIVATED 


Figure  22.      Deactivate  Pseudo-code 
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the  secondary  storage  location  of  its  "OAi^e  tal:le  frorn  the 
G_AST,  allocating  the  required  airount  of  main  rreriory,  and 
readini?  the  segment  into  the  allocated  main  memory.  The 
see;ment  must  "be  active  before  it  can  te  swapped  into  core, 
and  the  required  main  memory  space  must  "be  availa'ble.  Three 
conditions  can  "be  encountered  during-  the  invocation  of 
SWAP_IN.  The  segment  can  already  te  located  in  ^lotal 
memory,  the  segment  can  already  be  located  in  one  or  more 
local  memories,  or  the  segment  may  only  reside  in  secondary 
storage . 

If  the  segment  is  not  in  local  or  global  memcry, 
local  memory  is  allocated,  the  segment  is  read  irto  the 
allocated  memory,  and  the  appropriate  entries  are  made  in 
the  yf'll  image,  the  I_AST  and  the  G_AST.  If  the  segment  is 
already  in  global  memory,  it  can  be  assumed  that  the  seerrent 
is  shared  and  writable.  In  this  case  the  only  required 
actions  are  to  update  the  G_AST  and  I_/3T.  The 
Mo_Acti ve_In_Memory  field  of  the  G_AST  entry  is  incremented, 
and  the  "^MU  ima<?e  is  updated  to  reflect  the  swapped  in 
segment's  core  address  and  attributes. 

If  the  segment  already  resides  in  one  or  mere  local 
memories,  it  must  be  determined  if  the  segment  is  "snared" 
and  "writable".  A  segment  is  "shared"  if  it  exists  in  rcre 
than  one  local  memorv.  a  segment  is  "writable"  if  one 
process  has  write  access  to  that  segment.  If  the  segment  is 
not   shared   or  not   writable   and   in   local   memory,   the 
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appropriate  entries  are  updated  in  the  [^!^'J  ira^e ,  the  I_\ST, 
and  the  C-_AST.  If  the  sep-ment  does  not  reside  in  local 
memory,  the  required  amount  of  local  memory  is  allocated, 
the  5ee:ment  is  read  into  the  allocated  memory,  and  the 
appropriate  entries  are  made  in  the  MMU  image,  the  L_AST, 
and  the  G_AST. 

If  the  se,?ment  is  shared,  writable,  and  in  local 
memory,  the  segment  must  he  moved  to  global  memory.  If  the 
segment  is  not  in  the  memory  manager's  local  memory,  it 
signals  another  memory  manager  to  move  the  se^emert  to  p-lobal 
memory.  After  the  segment  is  moved  to  global  memory,  the 
memory  manager  signals  all  of  the  connected  memory  manager's 
to  update  their  I_AST  and  MMF  data  bases.  When  all  local 
data  bases  are  current,  the  memory  manager  updates  the  G_A.ST 
and  returns  a  success  code  of  seg_activated. 

The  pseudo-code  for  SWA?_IN  PIlOCSrURi;  is  presented 
in  figure  21.  The  arguments  passed  to  SVAr_I\'  are  the 
G_AST_INDEX  of  the  segment  to  be  moved  in,  the  process' 
rpE_#,  and  the  access  authorized.  S'//AP_IM  vill  convert  the 
segment  size  frorr  bytes  to  blocks,  and  verify  that  the 
process'  core  will  not  be  exceeded.  If  the  virtual  core  will 
be  exceeded,  a  success  code  of  "core_space_exceeded"  will  be 
returned.  If  write  access  is  permitted,  the  writable  bit  is 
set.  Checks  are  then  performed  to  determine  the  se^rrent's 
storage  location  (local  or  global),  and  the  appropriate 
action  is  taken. 
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SMk?    IN   PROCEDURE  (INTEX   WORD,  D'B?._U      B'^TE, 

\CCESS_AUTH      RITE) 
PET^TRNS    (Sl'CCESS_CCDE      3YTE) 
lOCAI      I_INDSX      -tfCRI),      LLKS      'VORD 
ENTRY 

ELKS    :=   CAIC'ILATE_NO._OF_?IKS    {G_AST  [INLEX]  .  SIZE) 
STJCCESS_CODE    :=    CK^CK_MAX_LINEAH_CORE    (£LKS) 
IE      SUCCESS_COrE   =   VIRTUAI_LIMEAP_CORE_EULL      THEN 

RETURN 
FI 

C-_AST[INrEX]  .NC_SEG,^ENTS_IN_>^.EMORI      *=      1 
IF        ACCESS_AUTE   =    WRITE        THEN 

G    AST  [INDEX]  .FIAG_2ITS    :=   WRITABLE_ErT_SET 
FI 
!    Leterrine    if    segment    can   be   put    in    local   nemnrv    ! 
IF   G_AST  [INDEX]  .FIAG_3ITS      AND      V/R  ITA£LE_^'ASr:    =    e 
OFIF      G_AST  [INDEX]  .NO_ACIIVE_IN_^E'^ORI    <"=    1       THEN 
!    Determine    if   already   in    local   memory    ! 
CHECK_IOCAI_r^E.^ORY    (L_AST_INDEX ) 
IF      NOT_IN    LOCAL_MFMORY      THEN 

AIIOCATE_LOCAI    MEMORY       (BLKS) 
READ_SEGMENT      TfAGE_TABLE_LOC  ,    iASE_ADrR) 
I_AST[L_INrEX]     :=    BASE_ADrR 
FI 
ELSE 

IF    not_in_global_memory    then 

UPDATE_KMn 
UPrATE_L  AST 
RETURN 
ELSE 

ALL0CATE_GI0BAI_ME.>10RY    (LLKS) 
if      IN_LCCAL_^'EMCRY      THEN 

^OVE_TO_GIOBAL    (L_INL'EX»    B^SE_ADDR,    SIZE) 
ELSE 

S  IGNAL_OTHER_MEvORY  [MANAGERS  ( I  NEEX,BASE_ADDR^ 
FI 
FI 
FI 

UPPATE_^'MTT_ivj^GE  frBR_#,SEG_^,BASE_ArrR  ,  ACCESS  ,ILKS) 
UPrATE_L_AST_ACCESS  (L_INrEX , ACCESS , rBR_^ ) 
SnCCESS_COrF  :=  SVAPPED  IN 
EMD     S'7A?  IN 


Fii'ure  21,   Swa?_In  Pseudo-code 
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6.   Swap  a  Segment  Out 

SWA?_CUT  is  invoked  when  a  user  desires  to  move  d 
seginent  out  of  core.  A  sei^nent  is  swapped  out  of  rore  Ij 
ottainin^:  its  secondary  storage  locatioa,  writing  the 
segrrent  to  that  location  (if  required),  and  deallocating  tne 
main  memory  used.  The  decision  to  write  the  segment  is 
determined  "by  the  G_AST  written  bit.  This  hit  is  set 
whenever  the  segment  has  "been  modified  .  The  segment  to  le 
swappe'^  out  car  he  in  one  of  two  states:  the  segment  can  Te 
in  local  memory,  or  the  segment  can  he  in  glolal  memory. 

If  one  process  has  the  segment  in  local  memory  aLd. 
the  written  bit  is  set,  the  sep-ment  is  written  into 
secondary  storage  and  the  local  memory  is  deallocated.  If 
the  written  bit  is  not  set,  the  local  memory  need  only  be 
deallocated.  If  more  than  one  process  has  the  segment  in  the 
same  local  memory,  the  segment  remains  in  cere.  The 
appropriate  P^^^^*  image  is  updated  to  reflect  the  segnients 
deletion  and  the  G_AST  i\o_Act  ive_I'',_Memc  ry  field  is 
d  ecrement ed . 

All  segments  in  global  memory  are  shared  and 
writable.  If  a  process  requests  the  segment  to  be  swapped 
out,  the  segment  remains  in  memory.  The  i^'V'U  image  is  updated 
to  reflect  the  segment's  deletion,  and  the  a_;ST 
No_Ac tive_In_Memory  field  is  decremented.  If  the 
No_Active_In_N'emory   indicates   that   one   process   has   the 
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segment  in  core,  its  nemory  mdnde^er  is  sif^nalled  to  no^e  the 
segment  to  local  memory. 

The  pseudo-code  for  S7AF_01TT  PEOCEruEr:  is  presented 
in  figure  22.  The  arguments  passed  to  S'VAF_OUT  are  the  E3P_# 
of  the  signalling  process,  and  the  G_AST_INrEX  of  the 
segment  to  "be  removed.  Tne  return  parameter  is  a  success 
code.  5'VA?_0UT  removes  the  segment  from  the  process's 
virtual  cere,  deletes  the  segment  from  its  M'^^U  image,  and 
decrements  the  No_Active_In_Memory  field.  If  the  segment  ':an 
he  removed  from  memory,  it  is  determined  wnich  memory  can  he 
deallocated.  If  the  see-ment  has  "been  modified,  it  is  v,ritten 
back  to  secondary  storage  and  the  appropriate  memory 
deallocated.  If  the  segment  has  not  teen  modified,  the 
appropriate  memory  is  deallocated.  If  after  the  deletion  one 
process  has  the  segment  in  x^iooal  memory,  its  memory  manager 
need  only  be  signalled  to  move  the  segment  to  local  memory. 
When  S'<i^AF_OUT  successfully  completes,  it  returns  a  success 
code  of  "swapped  out". 

?.   Deactivate  All  Segments 

DEACTIVATE_ALL  is  invoked  when  it  becomes  r^ecessary 
to  remove  a  segment  from  every  process'  adcress  space.  Each 
process  is  checked  to  determine  if  the  segment  is  active.  If 
a  process  has  the  segment  active,  it  is  deactivated  from  its 
address  space.  The  pseudo  code  for  Peac tivate_al 1  is 
illistrated   in   figure   23.   The   parameters   passed   to 


91 


SWAP_OTTT      PEOCiD'JRE    (DER_»i      BITE,    INDEX      'vOHD) 
RETURNS    (SUCCESS_COrE      LITE) 
ENTRY 

ELKS    :=   G_/VST[INDEX]  .SIZE    /  3IK_SIZE 
FREE_FROCESS    LINSAR_CORE    (£LKS) 
DEI.FTE_^Ma_ENTRY    (rRH_#,    SEG_#'i 
G_AST  [INDEX]  .NO_SSC-MENTS_IN_V'SMORY      -=      1 
!    Determine    if   segment   has   "beer,   written    into    ! 

IF    M^^U_I^'AGE[DPR_#]  .SDF[SEG_#]  . ATTRIFUTE?=WRITTEN    THEl 
!    If    segment   has   "been  written    into,    update   G_AST    ! 
G_ASTilNrSX]  .FIAG_EITS    :=   'v'RITTEN 
FI 
!    Determine    if    segment    is    in   gloljal   memory    ! 
IF    G_AST  [INDEX]  .&IO?AI_ADDR    ^>    NUII    THEN 

IF     G_AST[INrEX]  .no_ssg:^fnts_in_memohy  =  ? 

ANDIF      G_AST[INDEX] .FIAG_?ITS    =    WRITTEN      TrEN 
WRITE_SEG    (PAGE_1A£LE_L0C,    ME^'.0RY_ADDR) 
FREE_IGCAI_BIT_^'AP    ( r^E'"^CRY_ADrR  ,  rlKS  ) 
ELSE 

IF    G_AST  [INDEX]  .N0_ACTIVE_IN_MEM0RY    -    t;      THEN 

FREE_ICCAI_FIT_MAF    ( r^EMCRY_ADDR  ,  IIKS  ^ 
FI 
FI 
ELSE  !    If   not    in   f'lotal    memory    ! 

IF    G_AST[INDEX]  .NO_ACTIVE_IN    MEf^ORY    =    Z 
ANDIF    G_AST[INrEX] .FLAG_BITS~=    WRITTEN      THEN 
'A'FITF_SEG    ^PAGE_TAILE_L0C,    GLOSAL    ADDB^ 
F^EE_GL0iAL_5IT_^'AP    (GLC3AL_ADDR  ,"rIKS  ) 
ELS"'*'  ~ 

IF    G_AST  [INDEX]  .NO_ACTIVE_IN_^E^,ORY    =    f      THEN 

FREE_GIOBAI_BIT_MAP    f  GL'^3 AL_ADDR  ,    2IKS) 
FI 
FI 
FI 

S'ICCESS_CODE    :=   SWAPPED    OUT 
END  SWAP    OQT 


Figure   22,      Swap_Out    Pseudo-code 
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DEAC7IVATE_ALL  FROCSLUHE  (IKDEX   ./ORD,  L_INDEX   '^ORD 
RETURN?  (5ncCESS_C0rE   iYTE) 
ENTR^ 

LOCAL   I   BYTE 
I  :=  e 
DO 

IF   I  =  MAX  rER_#   THEN 

EXIT 
EI 

IE   L_AST[L_I\'PEX]  .SEGMEMT_NO/ACCESS_AUTK  [I  ] 
<>  ZERO   THEN 
SaCCESS_COCS  :=  LEiCTIVATE  (I,  INDEX) 
IE   SUCCESS_CCD£  <>  SEG  DEACTIVATED   THEN 

RETURN 
EX 
EI 

I  +=  1 
OD 

SUCCESS_CODE  :=  VALID 
END  DEACTIVATE  ALL 


Figure  25.   Deactivate  All  Pseudo-code 


93 


redctivate_all  are  the  deactivated  seffrrent's  G_;.ST  index  and 
the  L_AST  index.  The  I_AST  is  searched  bv  I}S?._#  to  determine 
which  process  has  the  se^rnent  active.  If  the  check  reveals 
that  the  segment  is  active,  it  is  deactivated  ly  calling- 
Deactivate.  If  the  segment  was  successfully  deactivated  from 
all  processes,  a  siicce5S_coQe  of  valid  is  returned. 

S.   Move  a  Segment  to  Glotal  Memory 

»^-^—^M^II  ■  ■■  —III  I  I    I    ■■!    M  ■■■  ^    I  III   ■  ■■  I     ■   ■  I  ■     ■■■   I  ■   I 

'^OV?_TO_PI.OIAI  is  invoked  when  it  tecome*:,  necessary 
to  move  a  segment  from  local  to  ."global  memory.  If  a  segment 
resides  in  one  or  more  local  memories»  and  a  process  with 
write  access  swaps  that  segment  into  core,  or  if  a  segment 
resides  in  in  local  memory  (with  write  access'/  and  another 
process  with  read  access  requests  the  segment  swapped  in, 
the  segment  is  moved  from  a  local  to  global  memory  to  avoid 
a  secondary  storage  access.  If  the  segment  resides  in  the 
running  memory  manager's  local  memory,  it  will  affect  the 
segment  transfer,  otherwise  it  will  signal  another  memory 
manafirer  of  a  connected  processor  to  affect  the  transfer. 
Figure  24  illistrates  the  pseudo-code  for  M0V3:_T0_GI03AI . 
Once  the  segment  has  been  moved  to  global  memory,  the 
signalled  memory  manager  will  update  the  MM'J  images  for  all 
connected  processes,  and  deallocate  the  freed  local  memory. 
k  success  code  of  completed  will  be  returned  to  the 
sienallin?  memory  manager.  The  parameters  passed  to  the 
memory  manager  are   the  segment's  I  AST  index  ,  the  global 
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M0V5_TC_ai0PAI    FROCEDURE    (L_INDEX      rfORT,    GLOBAL_ADCF.      VORD, 

SIZE      IvOPD 
RETURNS    (S'JCC2SS_C0I)E      2YTE) 
ENTRY 
!    !^ove    segment    frorr   local    memory    to   Global    irienory    ! 
DO_MErO^T_.^O^E    (MEMORY_AI)DR,    GLOBAI_AEDR) 
L_ASTriNI?SX]  .MEMORY_ADLR    :=   AVAILASLE 
!    Update    the    t^^'V   ivr.cife    to    reflect    new   address    ? 
DO      Fnp_AII_DBR'S 

IF    L_ASTrL_INCEX]  .SEGMENT_N0/ACC2SS_AUTH    <>    f    AMIF 
!^'^U_I^AGE  [DiF_#]  .SDF[SEG_i^]  .  ATTR  IFUTES=IN_IOCAL    THEM 
MMU_I^1AGE[DBR_#]  .SCR[SEG    #]  .BASE_ADj?  :  =  GLOBAL    AIDR 
FI 

or 

SUCCESS_CODS  :=  VAIIL 
END  MOVE  TO  GLOBAL 


Figure  24.   Move  To  Glotal  Fseudo-code 
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memory  address  of  the  rove,  and  the  size  of  the  segment. 
This  inforrration  is  passed  because  the  G_AST  is  locked 
during  this  request. 

9.   Move  a  Segp-ent  to  Local  Merrory 

M0V?_T0_IOCAI  is  invoked  when  it  becomes  necessary 
to  move  a  sei^ment  from  global  to  local  memory.  This  occurs 
when  one  o^  two  processes  which  hold  a  segment  in  global 
memory  swaps  the  segment  out.  The  segment  is  moved  from 
global  memory  to  the  local  memory  of  the  remaining  process. 
Figure  25  illustrates  the  pseudo-code  for  ^10VS_T3_ICCAL.  The 
narameters  passed  to  the  memory  manager  are  the  segment's 
L_AST  ind^x,  the  global  address  of  the  segment,  and  the  size 
of  the  segment.  The  return  parameter  is  a  success  code.  The 
MMU  images  of  the  signalled  process  are  updated  after  the 
move  has  been  made,  and  the  global  memory  is  deallocated. 

le.   Update  the  M^U  Image 

nprAT?  is  invoked  following  a  r^OVE_TO_GI.:CEAL 
operation.  After  a  segment  has  been  moved  from  local  memory 
to  global  memory,  it  is  necessary  to  signal  the  memory 
managers  of  all  connected  processors  to  update  their  MMU 
images  and  L_AST  with  the  current  location  of  the  segment. 
They  must  also  deallocate  the  moved  se^^ment's  local  memory. 
Figure  26  illustrates  the  pseudo-code  of  UPLATE.  The 
parameters   passed   to   the  memory  manas-er  are  the  segment's 
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MOVF_TO_IOCAL  FHOCEEU^.i:  (L_Ii\DSX   •vG?D, 
(SUCCESS  CODE   iYTE ) 


GLOBAL  ADD^   -'/OHr, 


END 


RETURNS 

ENTRY 

ELKS  :=  SIZE  /  ELK_SIZF 

3ASE_ADDRFSS    :=   ALLOCATS_LOCAL_rEr^ORY    (31KS) 

Move    fror  riobal    to    local    nenorv    I 

MEMORY    MOVE    (GLOiAL    AILE,    IASE_AErRESS  ,    SIZE^ 

L_AST[L_INEEX]  .MEM0RY_AIJDR    :=   3ASE_ABDRESS 

DO      FOR_ALL_DBR'S 

IF    LAST[T_IMrEXl .SEGMENT_NO/ACCESS_AUTF    <> 


AN^IF 


MMU_IMAGETD3R_#]  .SDR[SEG_#]  .ATTRIi5UTSS  =  IN    LOCAL    THE; 
MMU_IMAGE[DBR_^]  .SDR[SEG_^]  . rAS E_ADDR :  =  BASE_ADDRFi 


N 
FSS 


FI 
OD 

SUCCESS_CODE  :=  VALID 
MOVE  TO  LOCAL 


Fie-ure   25.   Move  To  Local  pseudo-code. 
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TTPLATE      PPCCErTJK"    (L_INrE7      WOHD ,    GlO?AI_ArL?.      WOET, 

SIZE      WORC) 
RETURNS    (SUCCESS_CCDE      BYTE) 
ENTRY 
DO      FOR_AIL   DRR'S 

IE      1_AStTL_INDEX] .SEGMENT    NO/ACCESS_AUTE    <>    0   ANTIF 
yrn_lr^AGE  [rRB_#]  .SrR[SEG_i*r.ATTB  lEUTES  =IN_I  OC  AI    TFEN 
^MTj_iMAGE[D5R_#]  .£CR[SEG_#J  .SASE_ADrP    :  = 

GIOiAI    AT^LK 
II 
OD 

ELKS    :=   SIZE   /   ELK_SIZE 
ERSE    I0CAL_EIT_MAP    ('^E^'ORI_AD^R  ,  ELKS  ) 
I_AST[L_IMBEX] .MEMORT_ALLR    :=   ACTIVE 
STTCCESS_COrE    :=   VALID 
END  TTRDATE 


Fip-ure   26.      Update    Pseudo-code 
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L_A?T  index »  the  new  plobal  address  for  the  segment,  and  the 
size  of  the  segment.  The  return  parameter  is  a  success  cede. 

■5,   SUI^'^AEY 

In  this  chapter  the  detailed  design  of  the  memory 
manager  process  has  teen  presented.  The  purpose  of  the 
memory  manager  was  outlined,  followed  hy  a  detailed 
discussion  of  the  memory  manager's  data  "bases.  The  desie-n 
presented  has  identified  ten  "basic  functions  for  the  memory 
manager.  The  implementation  details  of  these  functions  are 
presented  in  Appendix  A.  The  success  codes  returned  "by  the 
memory  manager  are  presented  in  fi.pure  2?. 

This  design  has  assumed  that  the  ';^ernel  level 
inter-process  synchronization  primitives  will  "be  Saltzer's 
signal  and  wait  primitives [15] .  This  fact  dominated  the 
design  decision  to  lock  the  G_AST  in  the  user's  process 
"before  it  signals  the  memory  manager.  In  a  multi-processor 
environment,  the  possi"bility  of  a  deadly  embrace  exists  if 
the  memory  manager  processes  lock  the  G_AST.  Should  follow 
on  work  implement  eventcounts  and  sequencers  as  kernel  level 
synchronization  primitives,  the  locking  of  the  G_AST  and 
memory  manager  synchronization  will  need  to  he  rpaddressed. 


99 


SYSTEf^   WIDE 


KERNEL   LOCAL 


INVALir 
SWAPPEE    IN 
SWAPPED^OQT 
SEG_ACTIVATED 
SEG    DEACTIVATED 
SEG~CPS\TED 
SEG_DELETSD 
VIRTUAL_COPE_ETJLL 
DUPLICATE_ENTR^ 
READ   ERROR 
VPITE    ERROR 
DRIVE^NOT    READY 


LSAE_SEG^!ENT_EXISTS 

NO_LEAP_EXISTS 

ALIAS_DOES_NOT_EXIST 

N0_CHILD_T0_DSLETE 

G_AST_IULL 

L_AST_EULI 

LOCAL_MEMORI_FULL 

GLOBAL  MEr^ORY_FULL 

SECONDARY  STORAGE  FULI 


MEMORY  MANAGER  LOCAL 

VALID 
INVALID 
FOUND 
N0T_F01TND 
IN_LOCAL_ME^^ORY 
NOT_IN_LOCAL_MEMORY 
!  +  DISK  ERRORS  ! 


Figure  27.  Success  Codes 
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IV.   STATUS  OF  RSSSARCF 

A.   CONCLUSIONS 

The  mernory  rnanager  design  utilized  state  of  the  art 
software  techniques  and  hardware  devices.  The  design  was 
developed  tased  upon  ZIICG'S  ZceCl  sixteen  tit  se^jiented 
microprocessor  used  in  conjunction  with  the  ZSeit:,  l^emory 
Mana^en^ent  Unit  [12].  A  microprocessor  which  supports 
segmentation  is  required  to  provide  access  control  of  the 
stored  data.  The  actual  implementation  of  the  selected 
thread  was  conducted  upon  the  ZP202  non-segmented 
microprocessor  without  the  Z££10  "•^MU. 

While  information  security  requires  that  the 
microprocessor  support  segmentation,  the  memory  mana^^er  was 
developed  to  "be  configuration  independent.  The  desip-n  will 
support  a  multi-proc'=ssor  environment,  and  can  he  easily 
implemented  upon  any  microprocessor  or  secondary  stcrap-e 
device.  The  loop  free  moaular  desie-"n  facilitates  any 
required  expansion  or  modification. 

Glohal  hus  contention  is  minimized  hy  the  memory 
manager.  Segments  are  stored  in  global  memory  only  if  they 
are  shared  and  writable.  Secondary  stora^^e  is  accessed  only 
if  the  segment  does  not  currently  reside  in  ^lohal  memory  or 
some   local   memory.   The   controlled   sharing  of   segments 
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optimizes  nain  nemory  usage. 

The  stcrasre  of  the  alias  ta'bles  in  secondary  storage 
supports  the  recreation  of  user  file  hierarchies  follcwine:  a 
system  crash.  The  aliasing  scheme  used  to  address  segments 
supports  system  security  by  not  allov/ing  the  segment's 
memory  location  or  unique  identification  to  leave  the  memory 
manager. 

The  design  of  the  distributed  kernel  was  clarified  by 
assigning  the  MMU  image  management  to  the  memory  manager. 
The  transfer  of  responsibility  for  memory  allocation  and 
deallocation  from  the  supervisor  to  the  mem'^ry  manager 
provides  support  for  dynamic  memory  management. 

In  conclusion,  the  memory  manap-er  process  will  securely 
manage  segments  in  a  multi-processor  environment.  The 
process  is  efficient,  and  is  configuration  independent.  The 
primitives  provided  by  the  memory  manager  will  supp'^rt  the 
construction  of  any  desired  supervisor/user  process  built 
upon  the  kernel . 

B.   FOLLOW  ON  WO^K 

There  are  several  possible  areas  in  the  SASS  design  that 
can  be  looked  into  for  continued  research.  The  complete 
implementation  of  the  memory  manager  design  (refine  and 
optimize  the  current  PIZ/SIS  code)  is  one  possibility.  Other 
possibilities   include   the  implementation  of  dynamic  memory 
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managerripnt ,  and  modifying  the  interfa'^e  of  tne  nericry 
manager  with  the  distrituted  kernel  using  eventcounts  and 
sequencers  for  inter-process  communication. 

The  implementation  of  the  supervisor  has  not  been 
addressed  to  date.  Areas  of  research  include  the 
implmentat  ion  of  the  file  manae-er  and  input/output 
processes,  and  the  complete  design  and  implementation  of  the 
user-host  protocols.  The  implementation  of  the  gatekeeper, 
and  system  initialization  are  other  possible  research  areas. 
Dynamic  process  creation  and  deletion,  and  the  introduction 
of  multi-level  hosts  could  also  prove  interes  tin^?. 
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APPENPIX  A  -  PL2/STS  SOURCE  LISTINGS 


MFMOPY  MANAGFP  PIZ  SYS  ^OPULE 


«  ^=  *  >:=   VEHS.  l.e 


CONSTANT 

FALSE 

>  = 

0 

TRITE 

j  = 

1 

AVAILAPLE 

;  = 

£    \    AST  ENTRY  A^AIL.  ! 

ACTIVE 

;  = 

1  !  1ST  ENTFY  ACTIVE  ! 

ZERO                  : 

= 

0 

NULL 

:  = 

^eeefc'' 

NULI_PAGE             : 

'  = 

0 

!     SUCCESS  CODES     ! 

INYAIir 

:  = 

e 

VALID 

;  = 

1 

FOUND                 : 

= 

2 

NOT  FOUND 

;  = 

3 

S'UPPED  IN             ! 

= 

A 

SNAPPED  CUT           : 

'  = 

c 
^ 

SEG  ACTIVATED 

:  = 

6 

SEG  DEACTIVATED       : 

= 

7 

SEG  CREATED           : 

,  = 

e 

SEG  DELETED 

•  = 

9 

LEAF  SEGMENT  EXISTS 

:  = 

10 

NO  LEAF  EXISTS         ; 

;  = 

11 

G  AST  FULL 

t  = 

12 

L  AST  FULL 

;  = 

13 

IN  LOCAL  MEMORY 

;  — 

14 

NOT  IN  LOCAL  "^FMCRY 

'  = 

15 

LOCAL  rEMOPY  FULL 

;  = 

16 

GLOPAL  MEMORY  FULL 

'  = 

17 

VIRTUAL  CORE  FULL 

:  = 

19 

DUPLICATE  FNTR^ 

•  = 

19 

NO  CFILD  TO  DELETE 

;  = 

20 

ATTPIPUT"  rAS:^S 
READ_MASE 
WRITE_MAS'^ 
CHANGED_MA?K 
IN_MEMORY_r<AS:: 
CLEARED 


=  %f2)11111110 
=  %f 2)00000001 
=  ?i^  (2)01000000 

=  %(2)00^'00100 

=  ?  !  CLEAR  AT' 


IrUTES  ' 


AUTHORIZED_ACCESS 
READ 


=  0 
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■in  IT" 
EXFC'TT? 

C-    fi.ST   FLAG   BITS    MASKS 
~      •<rHITArIE_'^ASK 
VEITTEN    MASK 


:=    1 
:=   2 


:=  256 

:=  £IK_SIZE    /    2 

:=  16 

:=  ?    !    SIZEOF    CIOIAL    r^.FiY    ! 

:=  ?    ISIZjlOI    ICCAI    me,^;cFY' 

:=  1 


DESIGN    P.\?AMFTT]^S  ! 

BIK_SIZE 
N'A7_PAGE_SIZS 
MAX_mSG_SI7S 
G_:^E^_SIZE 
I   I^IV    SIZE 
NO_OF~?ROCESSORS 

!    MAX    NUMBER    OF    DBR_'*'S  ! 

var    -ppp^    f\jp  :=   4 

~!    M/IX    EiNT^-IES    IN    G_AST  ! 

G_AST_IIMIT  :=    1^0 

!    MAT    ENTRIES    IN'    I    AST  ! 

I_AST_LIMIT  :=    100 

!    SIZE   or    ALIAS    TABLE  ! 

^^A7_^NTRY_N0  :=   32 

!    #    OF    SEGMENTS    PER    PROCESS    ! 
NO_SEG_EESC_REG  : =    64 

FIPST_FOSS_FFEF_BLOCK    :=      1 
PROCESSOR    LOCAI    DATA       ! 

PROCESSOR    ID  :=   0 


TYPE 


ArrPEss 


woRr 


ALIAS_nEADER   FECORL    [    SEG_PAGE_TA3IE_L0C         'VORL 

FAR_ALIAS_TABIE_LOC      ;/OrtD    ] 

ALUS  FECOFL    [    UNIGIIE_IC  ICNG    ^^"CRI 

SIZE  WORD 

CLASS  iORD 

PAGF_TArLF_LCC  WCFF 

ALIAS_TA5LE_L0C        WORE    ] 

SEG_DESC_REG   RECORD    [    BASE_ADDR        ADDRESS 

LI^IT  BYTE 

ATTRIBUTES      BYTE    j 

MMU  RECORD    [    SDR    ARRAY  [:\0_SEG_ FES  C_?  ^G 

SEG    DESC_PEG    J 
BIrlSJJSED        ~.vOPD 
MAa_PLKS  WORD       :=    ????    J 

G_AST_REC  RECORD    [   UNI0tte_ID1  LONG    WORD 

GLOBAL_i.DD^.  ADDRESS 

PROCESSORS    L    ASTE    NO    ARRAY 
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I    AST    R"^- 


HANTI' 


[NO_0'F_PrOCTSSCFS      VCFI] 
FIAG_5ITS  3iTE 

(J_ASTi:_NO_rAH  'VOP.r 

N  0  _  A  c  T  r;3:_  I  :\'_  M  Er^  cf  t    y  c  ?  r 
Mo_ACTrj?:_i::^??]N'LiiNTS  ',\^o^l 

SlZil  ',^G?D 

PAG'_TAILF_I0C1      WOFF 
AIIA5_TAEI5_L0C1      WORE 

INSTANCE!  WCPr 

INSTANCES  WOPD  ] 

PEC 0KB  [  ME:^ORY_ADrP         .arPRESS 
SrGi^E\'T_NO_ACCZSS_A''TH 

ARRAY  [^*AX_IPR_NO  '^'^'IZ]     j 

RECORD    r   UMCU^_ID2         LONG    V/ORD 
E    INPFI  aORl    ] 


^^A^IAPIE  PECLAPATICNS 


.  «i«  *j«  •,(*  ^«  ^^  «i«  ^i<  «i>  »i>  «u  -J^  -tV  o«  J^  «•'  .•-  <^<  u«  %f. 


^: 


^SECTION  G_rATA 
GIOPAI 


G_^ST  ARRAY    [G_AST_II"^IT      G_AST_PEC] 

GlOra.L    ME^    PIT    MAP      ARP^aYTG    MEMORY    SIZE/lc    ■vOFP] 


^SECTION    I    rAI-A 


^M'J_IMAGE  ARRAY     [^'ax_LpR_NG      .^'^'^ 

I_AST  ARRAY    [I  _AST_II^'IT        I_;<^T_RECl 

AIIAS_TA3IE      ^ECO^T       [    HEADER  AIIAS_HEADER 

All  A.S_ENTRY         A^.RAY 
[v^'lX_ENrRY_NO      ALIAS]     ] 
LOCAI_^EM_PIT_MA?    aPRA'''    rL_VE^'_S  I  ZE /16      '-10^1] 
DISK_BIT_'^Jip_PUFP    ARRAY    [????         FYTE] 
PAGE_TA±LE_EnrPZR    ARRAY     [PLK_?IZ^  LYTE] 


lee 


f  «l«  %Jf  «t*  kl«  <JU  U.  «■•  *!•  ^«  •■*'  ^O  'J^  ^*  •>!«  «U  k1«  ^  «»«  «i^  «4«  «l^  «l«  JLf  •J«  •'«  %><  *i,  .U  «<^  O*  «**  sU  -J'  «>'  vl«  «''  sf*  -•«  >.•'  «'«  '«<*  ^*,  ^t,  «*«  >•.  >•-  0«  v*^  >>•  %•-  «.««  V**  ^*'  '>>•'  <*>  «'-  "*'  "*'  •»'« 

I     *,*  *|%  *|»  ^1*  *|*  >]■»  *|»  »,*  *j»  *,»  *,*   «",»  ^(*  ^»   «^«  *|*  *,^   *^»  ^1*  *|»  «|V  *,»  *■(*  *,»  'I*  ""i*   *|»  *|»  *|*  *|*  »!»   *j»  -^^  *4"»   *|»  *|*  '!«  *t*  1*  '(*  *l*  •■(^  't*  1*  •^^  *(*  'f*  'I*  '<*  'l*  'l*  'I*  ')*  'I*  'l*  'P  'I*  'P  '(* 

■•'        The    ^ollcwint;    procedures   are    cored    ir    PLZ/AS^   and    are      -•= 
*        contained    in   a    seoarate   PLZ/ASM   rodule.  * 

BFAr_?AGi    PF.OC^rTT?S    (riSK_IOC      AfCP.r    ,    Ml^^ORY_Airx-.      AITF.ESS' 
RETURN'S    (    SlJCCESS_rorE        BYTE    ) 

HEAI)_SEGYENT    FROCECURE    (PAGE_TA5IE_I0C      iORD    ,    ME>:^,0?I_ADDR 

ArrpEss  ^ 

RET'JRN?    (    S'JCCESS_CODE      2TTE    ) 

"iRITE_PAGE   PRCCSCURE    (DISK_LCC   -^ORL    ,    FRO^_ArrR      ADrRESS> 
RST7RMS    (    ^TJCCESS_CODE    BYTE    ) 

VRITE_SEGMENT    PROCEDURE    (PAaS_TABLE_IOC    WORD    ,    EROM_ArER 

ADIKFSS) 
RET'JRMS    (    S'ICCESS_CODE      BYTE    ) 

READ_DIS^_BIT_'^A?      PRCCEDURE 

FETUFN'S    f    5lTCCES?_C0rE      BYTE    ^ 

■'rRITE_DISr:_BIT    N*'.?      PROCEDURE 

RETURNS    T   SUCCESS _COrE        BYTE    ) 

^EA?CE_DISK_BIT_^AP   PROCEDURE    ( STAFT_SRCF_LCC      'a^OFD^ 
RETURN'S    (    SUCCESS_CODE      BYTE,    BIE_IOC         WORD       ) 

CIEAR_DI<^K_FIT_MA?      PROCEDURE    (    BLY_IOC        WOFT    ) 

EREE_GI0BAI_BIT_^''AF      procedure    (ADFR      ADDRESS,    3IKS      ''/ORD) 

??EE_ICCAI_BIT_f^AP        PROCEDURE    (ADIP      ADDRESS,    PDI^S      VORr> 

AIDOC_IOCAI_^EMO?Y   PROCEDURE    (3DKS      WORD) 

RETURNS    (    S'TCCE5S_C0DE    BYTE    ,    BASE_ADDR      ADDRESS    } 

AID0C_GI0BAI_^'EM0RY      P^.OCEDURE    (BDKS      WORD) 

RETURNS    (    S'-'CCESS_CODE      BYTE,    BASE_ADDR      ADDRESS     ^ 

GET_UNIO_ir   PPOCEDURE 

RETURNS  (  ID    lON'G  WORD.  SUCCESS_CODE   3YT^  ) 

MEMORY_MOVE  PROCEDURE  (TO  ADDRESS,  ERO."^   ADDRESS,  SIZE  WORD' 

VALIDATE_r^SG   ^ROCEDnPE  (msG    ARRAY  [mAX_MSG_S  I ZE   BYTE]  ) 
RETURNS  (  FUNCTION  BYTE,  ARGUMENTS   ARRAY   [6  WORD]  ) 


le? 


VAIirAT3_'';ATT_'''SG   FHOCSIUEE  '^^SG   ARRAY  [^AX_r'S'"  _S  I  ZZ   PYTE]  ^ 
RET'J^N'?  f  SUCCESS   BYTE  ) 


INTERNAL 


T«l«  «•«  •.!•  ^f«  •!«  *JU  JU  «*•  «1»  V^  U«  «J«  «l.  OU  ^t>«)«  «.!«  U«  «)'  O^  U<  «''  «tjt  «.*«  ^'^  •■'  J«  -JL>  «'«  «»«  -J*  k*^  «■«  «!.«  •^>  •.^f  V  -''  ^'  "J'  •'*'  *'^  V'  ■-''  "'•■  «*'  ^l'  '•''  «*'  ■^'  -''  *^' 
'«*  '(*  *i*  'i-  'i'  n*  1*  't*  1*  ''i*  'i*  'I*  't*  'n  'r"i*  'i*  '«*  •»*  i"  i'  'p  'i*  i*  -i*  «t*  *%*  -nr*  t*  n*  'i**  'i*  *«*  't*  'i*  'i*  ■'i*  't*  'r*  "i*  '»*  i*  't*  'i'  'i*  'i*  "f*  t*  'i*  'r*  *.*  "i* 


hi-  «.■*  ..'*  JL-  *»-  %)« 


-  The  RSAD_AIIAS_TArIE  Procedure  is  called  fror  the  * 

*  Create_entr/  procedure  and  relete_entrv  procedure.  * 

'•'  The  DTocedure  will  read  the  requested  alias  tarle  -'^ 

•''■  fror  secondary  s to rap'e  to  main  rerrcry.  * 

-1-  ')* 

«C  JU  «A*  «l*  «t^  •>#  «f«  y«  ^(«  0«  «l«  •!«  «1«  •!«  tJ-^  «*#*>«  «*«  *t,  «'>  (J*  k*<  «C  «t«  «*«  %U  •'.  *.''  «t,  0«  «''•  «.*-  «■•*  xi.  «'-  *t,  «l.  «t>  >.V  «**  •J'  ■.>•  «'-  %*«  %*«  «*<  <•*'  «'.  «''  «>-  *''  «<'  %!'  «''  «.*«  •^'  <-■-  «><  •■•'  I 

'I*  'r  -p  •»'  •(*  »i'  '!•  '.'  'i»  -I*  -i-  'r  'ff  -I*  'I* -I*  'r  'i*  '»*  '**  'i*  -i*  'i*  i*  'i^'r  'i*'i*  '>'•  'i^'p  "i*  'i*  'i-  'i*  'i"i*  'i*  'i*  't*  '»*  »i»  n*'**  'i*  '»-  'r  *»*  "»*  '<"■  'i*'i'  'i*  'i-  'i*  *»*  »i**  t  t 


HEAI)_ALIAS_TAEIE   PROCEIURE    (    All  AS  _!■  ISK_LOC      WORP, 

i^i^ORY_ArTR      Air 
RETURN'S    (    SUCCESS_COLE      BYTE    ) 
ENTRY 

S':CCESS_CCrE    :=   RrAE_?  AGE  (  All  AS_riSK_IOC  ,    MFMORI 
EfJD      READ    ALIAS    TABLE 


C  TTC  C   V 


.  ^>  .J^  t^*  «t«  «'.  ^>^  « 


-  The  WRITE_ALIAS_TAIIE  Procedure  is  called  frcn  the  '■= 

*  Create_entry  and  r'elete_entr7  procedures.  T^e  pro-  -^ 

♦  ce^ure  will  write  the  eppropriate  alias  tatle  fro.T"  '•' 
'■•  main  nerory  to  secondary  storaf^e.  '■• 

a*  %r« 

I*  'I* 

*■*  jV  j^ yi* y* Oj  ji,  ju *i^ «i. *i« wu  ^i^%u.>.  .'^y^kt,  .tj  ji,  y^  ji,  j»*  j»-  o*  »!*;'-  j'cj't  ^'  *'">';  Vi  ^:  **c  ^i  ;'i ?'<  i'c  5'c5'j  ;*i5'i  5'^/;  j'*  i'*;*;  "'i ;*;;*;  ?*;?**  i'c  ?*c  **'  s'ij'c  *';  f 

WRITE_iSLIAS_TABLE    PROCEDURE  (  ALI A5_riS -:_LOC   -./GRr  , 

^^EMCRY_ArrR   AIL?  ESS  ■ 

RETURN'S  (  SUCCSSS_CODE    BYTE  ) 

ENTRY 

S''C':'ESS_COr"  :=  V;FITE_PAC-E(AIIA5_riSK_L0C,  MEMORY_A^TR^ 
END   W-ITE  AIIAS  TABLE 


10S 


y    -,»  *■!%  *ji.  ^  ,,*  *.,*  «|»  «^  ^  ^'t  <^  '■'■'t*  ^t*  'i^  •'I*  'I*  "**  'I*  'i*  'I*  't*  *»*  •*»*  '<*  'I*  'I*  'I*  'r*  'i*'P  'i"  'i*  '«*  *>*  'i'  't*  '»*  1*  'I*  '1*  't-  'I*  'I*  'r*  'I*  *(*  't*  *T*  'I*  '1*  *r*  'i*  't*  'i*»  n*  'i*  *i'  '(* 

-  The   sy.P3.Cy._kllAS_TPll^   Froceiure    is    called   fror    the  - 

-''  Create_alid?_tatle    procedure.    The   procedure   will    step  * 

-'  through    the    alias    tahle   until    it    natcnes    the    passed  '•' 

*  U!iique_id   with   a    tahle    entry »    cr    the    table   has    teen  •'•= 

*  exhausted.    The   procedure    returns   a    success    code    of  =■' 

*  either   found    or   nct_found,    and    the   appropriate    indej  '•'' 

*  into    the   alias    table.  * 


.f.  »•.  .1.  >•.  • 


.  >>.  u<  >•.  .■•  >>.  . 


SFARCE_AIIAS_TAEI^   PROCErURZ    (    UNIOUE_ir      L0^1G    WCRI    ) 
PiT^JRNS      ''    SUCCr?S_C0r3      byte,    IN'L-ZX     b^ts    ) 
ENTRY 

INTEI    :=   e 

S-JCCISS_C0D2    :=    N0T_70'JND 

PO 

ir  INEEX  >  ^'AX_?NT?.Y_NO   TH?N     EXIT 
FI 

IF  ALIAS_TArIF.AIIAS_FNT?Y[lNDEX]  .U\'ICUF_IL  = 

UNlQUF_ir   THEN 
SUCCESS_COLE  :=  FOaND 
EXIT 
FI 

INEEX  +=  1 
OC 
^MD   SFAPCF  AIIAS  TAPIF 


I  y?  5*;  :*;  :'c  yt  ;*c  s*;  ;**  ;'; ; 


•  •i"  -I*  '»•  •»•  -»*  *»■• 


The    ■JPI)ATE_MMU_IMAGE   Procedure    is    called    from    the    In 
procedure.    The    procedure   will   update    the   MKU    ina/^e    of 
the   appropriate   process   with    the   trencry   location, 
limit,    and   a'^cess   authorization   for    the   passed    serpent 
nuFiher . 


kf<  V  ^'  "''  «'"  «■'• 
'r*  'I*  f  't*  I"  '»* 


UFrATE_^MU_IMAGE        FROCEFURE    fBFR_NO   FYTF,    SFGMENT_NO      FY 

ACDR      ADFRESS,    ACCESS      BYTE,    LIMIT      B^TE 
LOCAL      iSTTR      BYTE 
FN'TFY 

MM!J_lvAGE[CB^_.\'0]  .FDR  rSE&MSNT_MO]  .BA£E_AI'DR       :=      AFFR 
MMU_IM^GErCBR_NO]  .SPR[SEG^ENT    NOj.LI^IT    :=    LI^^IT 
ATTR    :=    MM-T_i^jj^QE^ppp__f^Q]  .sFRTSEGi^EN1_MC]  .ATTFIIUTFS 

!      CLEAR   PREVIOUS    ACCESS       ! 
IF    ACCESS    =   READ    GRIF    ACCESS    =   WRITE      TEEN 
ATTR    :=   ATTR   AND   '!^(2)llllllie 


m  -p 
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ELSE  I       E7ECITTE   ONTY    ACCESS       1 

ATT^    :=    \TT?.   AND   %( 2)11112111 
EI 
MM7    lMilGE[r2?._N0]  .srH[SEG^^ENT_N'0]  .ATTBIP^TES     :  = 

~  ATTR   0"^   ACCESS 

END   UPDATE    vvu    I^/AGE 


f*l*  *•*  «)U  ••*  OU   »•*  »>*    %X0  *l*   J*   «l^    ***  •'*  «l#    »•*  •J*   «(«   »•*  V«    ^li.  *•*  fcl*   vt*  «tia  ^t^   »•*    *l«  ai«    O^    «t«  »•*    O*  *.*■*   »•*  »*»   J*  »•*    *'*    »•#  *•*    *'*  S**    ***  **'   »''■  *'*   •'*   V*^  »'i*  »•»    %•*  ^*    *,'i    *•*   »'*   »',   *'■    *'^  »•* 
»,■•  *(«  i-,^  *,»  ^,%  *,»  ^(*  *,•  «,«  *,%  ^,»   ^,^  ^*  *,-»  *f»  *,■»   »,%  ^j%  *,*  *,,  *,»  ^,»  r,'*  *|-»  rf-p.  *|»  ^^-i  «|«   ^|»  »f*  *,»   *!■.  t"!*  *^»  *|»  •p  »i*  *'i"»  *,•»  *!■*   *(»  *,»  *^»  *■!»  *^*  *|»  »,•  «^*  #|»  -,*   'I'*  '|«  •■(*   *(■*  •'i*  «■.*  ',"*  'r*  'l"* 

*  Thp  rEIETE_^^MU_E.MTRT  Procedure  is  called  frorr  the  Out  - 

*  procedure.  The  procedure  will  null  out  the  ^M^"^  imdfe  '•- 

*  of  the  appropriate  process  for  the  passed  segrrert  '•' 

*  number.  * 


TEIETE    MVTT_EMTFY      PROCEEUBE    (    r5R_NG   JYTE.    SEGME.MT_NO   iYTE    ^ 

r^MU_IMAGErDPH_NG]  .SrR[SEGyi^NT_NO]  .£;SE_ADLP    :=    NUII 
^^MH    lvAGE[rrR_rvIC]  .srR[SEG^EMT_MO"!  .Ilr^IT    :=    ZEFO 
K^^U"IVAGE[E3R_M0]  .STR  [SSG^:ENT_VOi  .ATTRIPUTZ5    :=    CLEARED 
END   DELETE    ^f^.U   ENTRY 


»%>*  ^O  «^^«U»f«  «*««!«  «l««fU  *,l*y«  *>««!*  sA*  v>**tl*  «l«  «l«  aj*  «*<  V' «*«  ^''^''^■U  V'  *^*0«  «V  «•««>«  «.''  «t^  «*'  «*>  «''«*«  «f-  V'O*  «.>'  »'«  •^>«  «*•  «'««*,  *.'-  «•«  <k'o  «t,  «*.«**  ^<.  O^  «t^  «>>.  «»«  %t,  ««^ 
*,»  »|»  »..  ri«  r,*  *|»  *,»  oj*  «|K  *,»  S^%   ^«#|«  *,»  «,«r,«  ^|«  V)'*  «|«  r,»  *(»  »^«  ^|«  •^^  *!««  ^*  ^f*  »p  *,*  *(*  *,»  i^f  i*  I'l*  *,«  *,*  »,*  *■]*  *,*  *j»  *,»  *|%  ■'i*  »|*  *,»  *(»  *|>.  ^,*  *i*  *,^  *,■*  »|»  *,*  •■,*  *|»  #,*  fi*  ^,«  *,» 


* 


The  FIMr_S^CONrART_STORAGE  Procedure  is  called  frcr 
the  '\.lloc_5ec_s tora^-e  procedure.  The  procedure  will 
s^^arch  the  secondary  storage  hit  iraD  to  find  a  cor- 
ti-^uous  storage  location  in  secondary  storap-e  for  the 
required  numter  of  hlocks  passed.  The  procedure  will 
return  a  success  code  cf  either  valid  or  irvalid. 


•I-  »*«  ij,  «(««•,  UL.  . 


EIND_SEC_5T0RAGE    PROCEDURE    (    RLKS    '.nRr     ) 

RETURN^:    (STtccESS_CCDE   PYTE,TA5LE   ARRAY    [LLK_SIZE   -vCRD]  ^ 
LOCAL      INDEX      WORD 
I  WORD 

ENTRY 

S'JCCE?S_CODE    :=    READ_DISK_B  IT_yAP 
IF      SrCCESS_CCDE   ^>   7ALID      TFEN 

RETURN 
FT 

INDEX    :=   T='IRS'^_P0SS_FRES_5LK 
I    :=   7 
DO 

SUCCESS    CODE,    INDEX    :=    SEARCH   DISK    BIT    ^v\-    (INDEX) 


lie 


IF    SUCCESS    COu^   <>    VALID      THEN 

ro 

CLEAK_DI?K_rIT_rAF    (    TA5IE[I]     ) 
17      I    =    e         THSi\'  EXIT 

FT 

I      -=      1 
OD 

SUCCESS_CCrE    :=    SZC_STOR_EULL 
P.ET'JPA' 
EI 

TAIIE    [I]     :=    INTEX 
I      -=   1 

IF      I    =   BLKS      TEEN      EXIT 
FI 

or 

SUCCESS_CODE  :=  V^IIP 
ENE   FIND  SEC  STOP  AGE 


*  The  AIIOC_ONE_FAGE  Procedure  is  called  fT-on  the  Create  -" 

*  alias_ta"ble  procedure.  The  procedure  will  fird  ere  '•'• 

*  pa^e  0^  secondary  stora,s:e  for  the  creation  of  an  alias  -'' 

*  tatle .  This  procec'ure  will  retvrn  a  success  code  of    ■^' 
-'•  either  valid  or  inval  id .                            -•' 

»»«  J* 

***  «'«  «*•  **«  «'•  «'«  •*'  «*«  «*«  •**  *'«  •*•  «*«  «*•  «*«  »i#*i«  «*•  ^^  ^'^  «'«  O^  «i«  «v  ^fi*  V'  ^'^  ^''  *■**  ^^  ^''  ^''  V'  *'*  ^'  ^'  *''  «*'  ^''  *''  ^'  ^''  «''  v*'  ^''  ^''  «''  ^''  ^'  ^''  «''  *''  *'V  «*'  «V  ^'  «''  ^^  «*'    fl 

•(•-   »(•  »|*  *4*  *!*  *|»  *(•  'J'  *|*  »|»  »,»  »|«    *j»  •,*  •(»  »j>  »j»  #1*  ■^^  »!*  »|»  *|^  ^|»  *|5  *j-»  >|*  *i»  *j*  *i»  *|*    *,»»|»  ^,»  *!•»  *|»  *■,%  >|»  «|«  *,»  *|»  *p   *,»  ^p  #l«  *|>  »,»  *,H  ^*  *|*  »,*  »!*   *,»  *j*  ^p    »jt   *,»  *|»  ^|«  *,»     I 

AILOC_CNE_PAGF      PRCCEPUPE 

PETURN'S         f    ?IJCCESS_COrE      BYTE,    FAGE_I.OC  *  TIC^.'      V;ORr    ) 

LOCAL      TABLE      ARRAY [BLK_SIZE      WORD] 

EMTPY 

S7CCESS_CCDE,    '^i.BLE    :=    EINE_SEC_STOR  IGE    (    1    ) 
IE        S^'CC^SS_COr'E   <>    VALIC      TFEN 

FET^TpM 
FI 

FAGE_LOCATION:=    TABLE l?] 
END      AILOC    ON'E   PAGE 
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The    iiIIOC_SI]C_STG?.AG"   Procedure    is    called    fror    the 
Cr^a  tp_pr.tr7   procedure.    The   procedure   will    create    a 
pape    tatle    frorr,    the    allocated    secondary   storage,    and 
write    this    pas-e    to    secondary    storage.    This    procedure 
will    return   a    success    code    of    valid    or    invalid. 


3YT?    ) 


1    ) 


AILOC_SEC_STCIiAC-T      PROCFTUHE    (    PLKS      "iCRP    ) 

RETUHMS    (    PAGE_TAPIE   IOC        '.'/O^.E ,    SUCCESS_COEE 

LOCAL      TAPIE      ARRAY   TBLK_SIZE      wqrd] 

EMTPY 

S^ICCESS_COrE.    TASIE    :=    FIN"D_S5C_ST0PAC-E    (    PLKS 

IF   ST-^CCESS_CODE   <>    VAIIP      THEN 

PET7PN 
EI 

PAGE_TAPLE_LOC  :=  TABLE  [£■] 
I  :=  1 
DO 

FAGE_TAPLE_PUEFER  [l-l]  :=  TAPLE  [I] 

IE   I  =  ELKS   THEN   EXIT 

EI 

I  +=  1 

or 

CO 

IF   I  =  MAX_PAGE_SIZE   THEN 

E7IT 
EI 

PAGE_TA2LE_BUFFER  [I-l]   :=   M'JII_?AGE 
I  +=  1 
OD 
SUCCES3_C0rE  :=  VPITE_PAGE  (  ?AGE_TABIE_LOC  , 

;t^PAGE  TAPLE_IUFFER  ^ 
E.MD   ALLOC  SEC  STORAGE 


#l«  «|k  V|«  '!«  «f*  > 


^*  «t**^«  «t*  ^«  0«  «l«  «J«  «l«  ^^  mj^   O'  *i«  «'«  v'«  «'«  ^^  «'«  «J«  «'* 


.  'kUr  *J*  «'«  0«  U« 


,  «U  ^,  U«  «(« 


The  CHEATE_ALIAS_TAPLE  Prccedu:-e  is  called  hy  th«  - 

Create_entry  procedure.  The  procedure  will  allocate  * 

secondary  storage  for  the  creation  of  an  alias  table  ^' 

and  update  the  ir.entor  se^rent's  alias  tahle  to  reflect  '■'• 

the  created  alias  tahle's  secondary  stora^^e  location.  '•' 

The  procedure  returns  a  success  code  of  either  valid  * 

or  invalid.  -'• 
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CREATE    AIIAS    TAEIE      F-OCED'JP.E    (    ?AH_INrEX      WORD    ) 
RRT"RN^    T   SUCC?3S_C0rR        EYTE    > 
lOCAI      PAREMT      E^TE 

ALIAS_TABLE_LOC      iORD 

EMTFY    MC      PY?E 


EMD 


EMTR"^ 

S7CCESS_C0DE    ,    ALIAS_TABIE_ICC     :=    ALIOC_ONE_rAGE 
PARENT    :=  G_AST  [FAF_INrE7]  .C-_ASTE_NO_PAP 
SUCCESS_CODE    :=  HEAD_AIIAS_TASLS  (G_AST  [PA^EN'!']  . 

iiIIAS_TAi3lE_I0Cl  ,    #ALIA5_TA£LE    ) 
IE    >T;'CCES^_COrE   <>   VAIIF   TFEN 

T'ETURiM 
EI 
SUCCESS _CnrE,    ENTRI_N0    :=    SEARCE_AIIAS_TABLE^ 

G_ASTrPAR_INDEXj  .UNICrE_iri    ) 
IE      SUCCESS_COrE   =    NOT_E0UND      TFEN 

RET^'^HN 
FI 
iiLiaS_TA5IE.ALIAS_ENTRY[ENTRY_N0]  . AIlA3_TAIir_I0C    :- 

ALIAS_TAFIE_ICC 
G_AST[PAR_INDEX1  .  All  Ar_TABLE_IOCl    :=    AIIA<^_TAFIE_ICC 
SUCCESS_CODE    :=   V/RITE_ALI  AS  _TAFLE    (    AL  IA5_TAILE_L0C, 

^AIIAS_T«FIE  ^ 
CREATE  AIIAS  TABLE 


T»f*  »V  ^*  ^'  «t#  «1U    ^*«  *f0  »1^  ^^  ^U   V'  ^^  •'«    *^^^   «l^  ^*  OU  «<•  Wt*  «l«  aiO   «t#  «l«  *l«    v'«  «t«  *.t«    «t«%V    Orf   «>'^    «*•    «'^  •>l^  «*«   k'>    v'>  ^«    %*«    0>    OiT  v'v   «l»    ^*  «*«    <*''   «'i«  K*«     k^«  %*'    Orf    «'«   «'«    ^«  «>«    k*^    «V 
•|*  •'I*  ^*   '(»  *|«  *;*   ^'l^  *|»  *,•   #1*  *i*   J|»  *i*  *j«   «|«  »,»  «^  ^|«  ^1*  ^«  *,*  *l»  V|«  *,*  *f»  ^«   *|H  «,^  ^,*   #1*  «|«   *»(»   *|*  *",*   «|»  *,*  ^,>   *,»   *,•  ^j»   *|»   ^|«   -j»  ^,*   *j»  *,*  *,»   r,*  *|*  ^^    *,■»  >ii*   ^«    <>,*  ^|«   *,%  >)»  *,»  *1> 

*  Thp  CFEC'^_^^AX_VIRTlTAL_CORE  Procedure  is  called   - 

*  "by  the  In  procedure.  The  procedure  will  verify  that  ""•' 
-'  th®  addition  of  the  segment  requested  to  te  <^wapped  in  '•" 
'•'  will  not  cause  the  process'  allocated  virtual  cere  tc  ■•'' 
^  he  exceeded.  If  the  virtual  core  is  not  exceeded,  a  '•• 
••'  success  code  of  valid  is  returned,  ctnerwise  a  success  '•' 
^-  code  of  no_rencry  is  returned.  * 

CHECK_MAX_VIRTUAL_CORE  PROCEEURE  (  EFR_NO   BYTE, 

FIE_NO_REC   WORE  ) 
RETURNS    (  3UCCESS_C0EE     EYTE  ) 

ENTRY 

^''^U_P^i-GErErR_MO]  .RIKS.USED    ^=    RIK_NC_FEO 
IE    :'^,f^U_I>^aGE[ErR_NO]  .IIKS  JTSEI      > 

^'MU_IMAGE[EFE_NO]  .rA7_I.IKS      TFEN 
r/r/TJ_lvi^C-E[L?R_NO]  .rIKS_^TSED      -=      £Ir:_NO_^EC 
SUCCESS_CCrE    :=    VIRTUAL_CORE_EULI 
EISE 
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S^TCCTSS    CC^-     :=    VAIIL 


71 


?.Kd      CFl^CK    ^AI    VI^.TUAI    CO?.E 


fju  ^  «A«  «i«  V«  Uf*  .ju  *.tp  «J«  *r«  ^*  •!<»  *u  %i«  «»«  ^*  o*  «.)-  «>«  «•*  «j«  ju  >c>  ^i«  .u  i.^«  o«  *••  o<  «i*  «i<  *'«  «t,  V  «>,  «t^  o.  ^>.  ^«  ^*  «•'  «i«  «i«  »>.  ^«  «v  «•.  «t- «'-  .j«  *>'  ^'  »>*  •«•'  «)-  «*«  •>«  « 
r|*  ^1*   *|*  •(^   ^*  *,%  *j%  Vj*  «>lp  ^l«  ^(*   V|«  *|«   *^%   ci*^!*   «|*    ^j%  *|N  r|*  ^,*  *■,>   r^•%    *j%  «!'«  ^j%   *,•  «,«   ^,»  *|»  *j»   »|»  r^    #,•  *•,■»  *i"«  •■,■»    •■,*  *,*  >i*   *|»  ^,*   *,»  »,<•   *(»  *,»   »,*   *,»  *■!»  ^,«    #,»  *|»  ^,*   *,*  *|«   ^j^   «|«   * 

*  The  rFES_PRCC5SS_VIRTUAI_C0R^  Procedure  is  called  from 

*  the  Out  procedure.  The  procedure  will  su-tract  the 
'•'  size  of  the  segment  which  has  heen  swapped  out  frcr 

*  the  virtual  linear  core  allocated  to  that  TDrocess. 


r?EE_F?CC?!^?_VI?TUAL_CC?A   FHCCZrUPE  (  PIK_NC    '.''CPE  ) 

ENTP^ 

v!^U_IMAG^  [  rPH_KO  ].PLK3_U3Er  -=  5I?_N0 
END   Pr^E  PPCCESS  VIPTT"^AI  COH? 


* 


The  FPEE_SECOVLAPY_STOPAGZ  Procedure  is  called  fron 
the  Dolete_seg  procedure.  The  procedure  will  read  tne 
pap-e  tahle  of  the  se^rent  to  "be  deleted  and  the 
secondary  storaiS-e  lit  map  into  main  nemorv.  The  lit 
rrap  will  he  cleare^  to  reflect  the  deallocatior  cf 
secondary  storasre,  and  the  pa2'e  tahle  location  will  If 
cleared.  The  procedure  returns  a  success  code 
valid  cT    invalid. 


of 


«*«  ;';  )';  ^i  ^*  ^*  ;>'  ^  •*'  '*' «'-  ^*  «*«  «''  «*'  «'•  '^'  «''  «*'  ^ 


t.  *X0  J.  *»* 


,  %J,  O^  -Jf   «•• 


7PEE_SEC_STCPAaE    PROCEPURE  (  ?A';E_TAPIE_I0C   "■'OPP  ) 
RETUPM5  (  SUCCFSS_COrE    PTTE  1 
lOCAL     I      '.VOPD 

TAELSl   ARRAY  [  ri:-:_SIZE   VORL  ] 
ENTRY 

SUCCESS_COPE  :=  REAP_PAGE  (  FAGE_TA3I E_ICC  ,  -TAPIEl  ) 
IF   ST.TCCESS_COrE  ^>  TALIT  THEN 

RETrPN 
FT 

SUCCESS_CO^'E    :=   READ_DI5i:_BIT_r^AP 
IF    STTCCF?S_CCDP    <'>    VAIII    THEN 

RETURN 
FI 

I    :=   I? 
DO 

IF  TAPIE1[I]  =  MILL   ORIF  I  >=  EIK  SIZE   THEM 
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l^-\  i.  J. 


II 

CIEA?._ri??:_3IT_^AF    (    TA5IFlfI]     ) 
I    +=    1 


o: 


CIEA^-_DISK_5IT_i^A?    (    FAGI_T A3Ia_LCC    ) 
SUCCESS_COD^    :=   7ALID 
END      7?EE    ^IC    ?TO?.AGI 


The   DI!I?]TE_SEG   Procedure    i?    called    fr^m    the    lelete 
entry    procedure.    The   procedure    will    -free    secondary 


>!» 


storare 


f  A- 


the  deleted  sepment,  and  null  out  the 


entry  in  its  n^entor  segment's  alias  table.  The  pro- 
cedure returns  a  success  code  of  either  vdlid  or  in- 
valid , 


DEIETE_5ZG   PFOCETURE  (  ENTRY_NO   ;i'OFr  ) 
RETURNS  (  SrCCES:_CGrE   2YTE  ) 
ENTRY 


c;  'J  v^  I-'  ^  c  ^  o  vj  J.  _i 


:=  FREE  SEC  STORAGE ( 


AII.AS_T;3IE.AIIAS_rNTRY  [EKTRY_N3]  .FAGE_TA2LE_I0C  ) 
IE    SrCCESS_COrF    <>    VALIE      THEN 

RETURN 
EI 

IF      ALIAS_TAIlE.AIIAS_EKTRY[ENTRY_NO] . ALIAS_TA5IE_ICC 

<>      MULL      THEN 
CIEAR_T'ISK_BIT_MflF( 
AIlAS_TAFLE.AIIAS_E;JTRY[ENTRi_NC]  .  All  A5_TArIE_ICC  = 
FI 

J>IIAS_TABIE.ALIAS_^N':'^T[EMTRY_^!0]  .UNICUE__IE      —      ir^ll 
?\'C      lEIETE   ^EG 


J;;c5 


.  *t,    «#<.    4j«    *>^    . 


-  The  CHEC?:_IF_AIIAS_Er^PTY  Procedure  is  called  tv  the  - 
'•'  De le te_'=nt ry  procedure.  The  procedure  will  search  tne  ••■ 
'^  alias  talle  to  deterrr.ine  if  the  tahle  is  erpty.  I''  the  "= 
'■'  alias  tahle  is  erpty,  the  varia"ble  Alias_ta  ole_en^p ty  '•' 
^-  is  Set  equal  to  true  and  returned.  If  the  tahle  is  not  '■' 

-  empty,  Alia s_taLle_empty  is  set  equal  to  false.  - 
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CHi;CK_IF_AIIAS_E^PTY      PPCGirURE 

?.ST7?NS    (    AIIAS_TA3I.i;_EMFTY      rYT3    ) 
LOCAL      I  BYTE 

I    :=   e 
DO 

IF  I  =  AIIAS_TABLF_LIWIT  TH3:.\' 
AI IAS_TAiI^_FMFTi  :=  TPUF 
EXIT 

IF    ALlAS_TArLF.ALlAS_FNT?.Yri]  .UhICUF_ir^>£    THEN 
ALIAS_T/l5IE_if^PTY    :  =   FALSE 
EXIT 
"^IS  E 

'^I    +=    1 
FI 
FI 
OL 
END      CFECI    IF   ALIAS    EMPTY 


»•;«  ••<  «.*«  ..I*  «l«  «l«  «L«  JL*  *l*  ^*  %r>  «;.  JL.  JU  •.#<  JU  •>l«  ^'  «'-  *'»  vu  •*'  **. 


*K,  *f^  %>,  o*  «l«  .!«  «i«  ^u  . 


•  %l«  O*  *'*  ***  *•*  »t^  »*»  ••*  &'«  ***  *J«  O*  »**  «l«  *•*  *'*  »'*  x''  ^l>  %'^  *'*  V'  *'*  •*'  **-  *** 

•  ^^*   «,«  JjY  «|«  «f«   »,«  «|*   ',«   #,«   «j'>  ^,^  «|«  '|«  «,«   «,«  «.o  «|%   'j«  v,«   rp   ^|«  ^i-k   't*  'i*  '1^  'I* 


The  CEEC>'_LOCAL_i'"^^^ORY  Froceiure  is  called  frorr  the  In  - 
procedure.  The  procedure  determines  if  the  ser-"ment  is  '"' 
in  the  processor's  local  rremory  "by  exar. inin^'r  the  ^"^7  ••• 
ima^'e  for  ea^h  ccr.nected  process.  If  the  se^rrent  is  in  '"' 
the    local   nernory,    the   variatle   Test    is    set    equal    to  -•' 

truet    otherwise    it    is    set    eq.ual    to    false.  * 


•>*•  «A*  «f «  (Jt*  «J<  «>«  tf«  «t«  <k*^  **«  -J*  «**  «r-  «*«  U«  •.t»«f«  *J^  it>^  «•-  «•«  «.**  k*-  •!•  «A*  •,!«  «|«  «JU  «U  *J*  «.'•  «t'  •.•-  «>^  o«  «l*  *.>-  o. 


«t«  U«  •.tv«f«  a^*  ^O  «•«  «•«  «.>*  k*«  •!*  «A*  *,*«  •!«  *JU  «U  iJ«  «i'«  «*'  •.<«  «>^  *k*«  «l#  *.'»  «J«  «ti.>  «•*  *.>*  «■«  «•«  «■'  «'<  «>«  «'*  •..'«  «>«  «<«  •,*«  •>!«  0<  •*#   k'«  0«  «l«  iJ^  «'''    I 

-r  'I*  'i-  '.»  'i»  'i*  'I'  'i*  'i*  'i*  'i'  't"  'I*  '^'  1*  't*  'I*  'I*  n*  't*  'I*  '••*  '1*  't-  -I*  'I-  'i*  '*•  'f  'I"  '1*  'i"*  't*  'i*  't*  'i*  'f  '.*  '--  'r*  '•■•  'i*  'i-  'r  'i"  't"  f 


CFECX_L0CAL_v'7vnp.Y      froCEDUxRS    (    INFEX      WORE    ) 
FETHPN?     (    T^ST      LYTE    ^ 
LOCAL  I  BYTE 

SEG_NO        FYTE 
=    2 


I 

DO 


IF    I    =    M/^x_D£R_NO      THEM 

TEST    :=   NOT_IN_LOCAL_'^F^ORi 
RE'^URN 
FI 
SEC-_N'C    :=    (    L.ASTriNIEX]  .SEGMENT    NO_ACCESS_iiUTH  [  I] 

ANE      ^(2^01111111    T 
IF    SEO_NO    <>    e      TEEN 

IF       f^^MTJ_lMAGF[I]  .SDRrSEO_NO]  .ATIPIFUTES       ANT 
IN_MEMOPY_MASK^       ^^    0      THEN 
TEST    :=    IN_LC/CAL_MEMORI 
RETURN 
FI 
FI 
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or 


I  ^=  1 


N'L      CH^CK    I3C/II    MZMOrY 


♦ 


The  CR?C^_FOH_R2;mOVAL  Procedure  is  called  ty  the  Deact-- 
ivate  procedure.  The  procedure  will  deterrr.ine  if  the  - 
sp^nert  is  active  in  any  I_AST  ard  if  it  has  dr.y  active'"' 
dependents.  If  the  se^rrert  is  ret  active  and  dc^s  not  '•' 
have  anr  active  dependents,  the  G_AST  entry  is  reroved.''' 


CHi:C^_FC?._RE^^CVAI   PP.OCEDL^EE  (  INDEX   WOKL  ) 
LOCAL     I     LITE 

TiST   LYTI 
EMTP^ 

TEST    :=   7ALS^ 
I    :=  e 


DO 


or 


IF    I    =    NO_GF_?POC^SSO?S      OPIF      TEST    =    TP'TE      THEN 

FT  IT 
FI 
IF    C-_AST[li\I}EX]  .?R0CESS0PS_I_A3TF_^0[li     <>    i      THEN 

TEST    =    TRUE 
FI 
I    +=    1 


IF    G_A?T  [INDEX]  .NO_ACTIVE_DEPENDENTS=? 
AMDIF      TEST    =    FAISS  THEN 

C-_AST[IN'rFX]  .rNIOTIE_iri    :=    AVAlLAxLE 
FI 
END    CHECK    FO^    RE.^OVAL 


I  5*c«  ^c  ^*''*'»5'c  ^c  J*^  j'?;*;  ^"^t  "^c  "^^t  ^'c  **€  j'c  ;'c ?*•  5*;  *''s  s'c ^'  5*;  •»-*<- »»-  y*;'-  yj;'c  "'li';  ;'jy;  ;';  ;'j*';  j*i  ^i  i'i^'  -•;*•*  *»*  j»j*'-ju  ;•;;■;  *v  *•;  ;•;  %♦-  *•;  ^\  »•- 

*  The  CFFrr_IF_OTHFRS_ACTIVE  Procedure  is  called  ly  the  - 

*  Delete_entry  Drocedure.  The  procedure  will  check"  to  '"' 

*  determine  if  a  segment  is  active  in  any  L_AST.  If  th«  '•' 

*  segment  is  active*  the  vcriahle  Others_ar'ti ve  is  set  -'■ 

*  ecual  ^-0  true,  otherwise  it  is  set  eqral  to  false.     '•' 

*  ::-- 

«ir  *f*«t«  »v«  «t«  ju  ju  ju  *^4t  »•'  »*<  '.^t  k><ki^  •!«  «j««i«  «i,  «*-  >''  oU  o.  «ju  vj**  .t«  «i«  «j«  **«.j«  «•«  ■j*.!^  «j«  kO  «i«  «•«  *.uo«  «•<■  -kV*^'  •>.■«  -.'-  Oxj-  -.'^^itf  N>«  «•'  .^o  u^  ^1,  «r^  s>.  ■>•<.  o^  ^.i^  .•>  ^r,    ■ 

'l*  '1'   'p   '(•   '■•  ',•   ',*   ',*   -t»   •■,■•   -,-   ',-    *■,■»  »>  *;%   *■,'.  -■,*   *■,■•   '»■•  'I*  "I*  ',*  'I*  ^*   "1*  ',»  'I*   II*  1*   'I*   •'|'»*1»   '|»  <-,»    '!•  •-,*   ',»  •!*  *,»  *i*  *|»  *,*  *,-.   *,«.  *»•   •■,>•  ry    ^1*  *,»  »p  -It  *,»  *,*   -J*   ',*  *!•  *,■»  *,%   *,*       ' 

CHECK_IF_OTKE?S_ACTIVE   PROCELURE  (  INDEX    WORD  ) 


117 


P?'^^Tp!^c;     (    OT^-RS    ACTIVE      BYTE    "* 
LOCAL    ^     I        "  EYT^"' 
ENTRY 
I    :=   e 

ro 

IE  I  =  NO_OF_PPCCESSORS  THEN 

OTFEPS_ACTIVE  :=  FALSE 

RETURN 
EI 
IF   G_AST[INrEX]  .PROCES30RS_I_ASTE_NO[I]    <'>    e      THEN 

OTHSRS_ACTIVE    :=   TPIJE 

RETl'RN 
EI 

I  +=  1 
OD 
ENE   CHECK  IF  OTHERS  ACTIVE 


-  The  ACTIVE_IM_L_AST  Procedure  is  called  ly    the  Feact- 

'■'  ivate  procedure.  The  procedure  will  search  the  Sej:- 

*  ment_#/Access_auth  field  of  a  secrr-ent  to  deterrine  if 

*  the  segrert  is  active  in  the  L_AST.  If  the  serment  is 
'•'  active,  the  variable  Check  will  "be  set  equal  to  True 
^'  and  Teturred. 


ACTIVE_IM_L_AST   PROCSriTHE  (  IMDE7    WORD  ) 
RETURNS  (  CHECK    PYTE  ) 
LOCAL     I     PYTE 

ENJTPV 

I    :=    ^ 

CHECK    :=   FALSE 
DO 

IF      I    =    ^^AX_EPR_NO      OR  IF    CHECH    =    TR'JE      THEN 

RET^'^RN 
FI 
IF    L_ASTriKDEX]  .SEGMENT_NO_ACCESS_AUTH    <''>    ? 

CHECK    :=    TRUE 
FI 

I    +=    1 
OE 
END      ACTIVE    IN    L    AST 


THEN 


f«f*  2*'  VS  S'*  «*f  »>  •'*•  •*•  «■•  2**  •*«  «'-  «*«  *■**  «•««*'  *'**  «*«  «U  U#  •,>«  ■st^  >U  0«  «l«  «JU  «l«  -kU  %*,  «C  *,!«  0«  sf(*  ^m  «^<  «&•  ^^  •J.f  •!«  aJU  «U  «•*  Ot*  0«  *l«  Oo  -J*  •-l«  U«  -'«  «J.  -JU  *l« 
*C  •!*  '•*  •»*  *!*  •■»•  *«*  •»*  *»•  *i»  *«*    •»*  *,*  *i»    ',>•'»'■  1*  'I*  »|*  "t*  'i*  *I»  'I**  'f*  'I*  *|»  •!*  't*   "I*   'l"*  '»■•   'I*  'i*  'I*  "I*  'l*  't*  '!■■  'I*  'n   'I*  'i*  *!*  "»■■  'l-*  ^-  'l*  'I*  'I*  'I*   'l'  "1*  "t* 


*  •^l.  <J«   .*«  a^*  «»« 


lis 


-  ThP   'T?r'flTE_I   AST_ACCSSS    procedure    is    called    cy    the    Ir  - 

*  'procedure.    TH"e    procedure   will    set    the    read/write    "bit  ••= 

'*'  of    the   appropriate    5e^ment_#/acce£S_au th    field    of    the  "^^ 

''•  I_^?T    ^c   a    one    if    the    Drocess   has    write    access    or    to    a  '•' 

'•  zero    if    the   process    has    read   access.  * 

^TPI)ATE_I_AST_ACCESS      FPOCErUP-i  (I  NDE7      aORI  ,  ACCE?S_AUTH    lYTE, 

DrP_NO      ETTE    ) 
LOCAL  S?:C-_KO  '.^ORD 

ENTRY 

SEG_N'0    :=   L_'^ST[IMrEX]  .  SEG^ENT_NO_ACCES  S_AUTH  [I'rE_i\"0] 
IF    ACC^SS_AUTK    =    WRITE      THEN 

L_A^TriNTEX]  .5EGMEMT_N0_ACCE?S_AUTH[rSR_N'C]     :  = 

SEG_NO      OR      %{2)127'^2^72 
ELSE 

L_ASTriN'rEX]  .<^EGMENT_^NlO_ACCESS_AUTHLrPR_NC]     :  = 

5rG_N0      AND      °i(2)eilllllll 
FI 
^NL      UPDATE    L   AST    ACCESS 


f  3*C  ^C  ^'  *'*'  **'  *''  3**  ^''  *'*''  *^'  ^''  "''  ^''  *'*'  ^''*'*-*  *''  *^  ■'*'  **'  **'  '^'  *''  ^''  *'*''  3*'  ^'  *^'  ^*  ^J''  "*«  '■*■'  ^''  ^''  *-^  *''  *''  ^'  3*'  **'  "''  ^''  "''  «*'  ^''  ^''  ^*-'  "''  **'  ^''  ^*'  •'^  ^''  ^''  ^''  *■*'  3*'  *"*'  *>*' 
«■•  *'* 

'i'  The  SFA-PCF_G_AST  Procedure  is  called  hy  the  Activate  -' 

••'  procedure.  The  procedure  will  search  the  G_A?T  to  '^ 

*  detertnine  if  a  passed  segment's  unique_id  exists  in  ''••' 

'■'  the  G_A^T.  If  the  unique_id  is  found,  a  success  code  -^ 

'•'  of  fourd  ard  the  G_AST  index  are  returned.  If  the  '^* 

^^  se^rrent  is  not  found,  a  success  code  of  not_found  is  -•' 

"^^  returned  .  -'• 

«VU  ^  ^d*  nV  V'  «f«  vA*  V  %U  -J^  *l«  -J*  «i«  «l«  «f'  «■*  <J»  u*  U«  ^t,  ^,  «J«  *l«  Om  «•«  *JU  s**  •>'  «*«  «**  ^A*  %<«  «1'  •*«  «1^  «J«  ^i*  *f»  «*'  ^I'l  <•**  «*'  «'«  «*'  »*'  «*'  •«*'  •>*'  "if'  ■■*'  •.'-  «*«  <■''  '*'  <>''  *''  V-*  o*-  t 
*|*  ^t**  'l*  *|*  r^   «(«  >j%  >j»  *,»  #^»  *,^  #1%  v|«  .J*  «|«r|«  *|*  ^%  ^«  *j*  «p  «■!«  *|>  ^j»  *|*  *^*  ^«  #|«  ^,«  *j*  rf*   *j»  *|^  «l«  «f*  .f,^  ^«  ^l«  »j»  ^,»  «|«  •[*  V|«  ^«  *j%  ^■j*  *j»  *,*  r,*  «|«  V|«  *(*  *^»  ^l«  *|»  *|H  i|»  *_»  f 

SEARCH_G_AST    PROCEDURE  (SEG_ID    lONGWORL) 

RETURNS  (SUCCESS    IITS,  INDEX    WORD) 

LOCAL    I  WORD 

ENTRY 
I  :=  e 
ILOOP:  DO 

IF  I  ->  G_AST_II^'IT  THEN 
SUCCESS  :=  NCT_FOUNL 
INDEX  :=  NULL 
RETURN 
FI 
IF  G  AST[I] .UNIOrF  IDl  =  SFG  ID  THEN 
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SUCCESS 


:=   FOUMD 

I 


FI 

I    +=   1 


or 


EMD   SEARCH   G    AS' 


fJU  V'  vV  «>#  WU  ^f*  .J*  0«  *t^  *J0  -J,  «(^  «lu  .wt*  ^«  •!«  ^«  »f*  i^f*  «.>«  •>'  «JU  0«  ^-  -J^  JU  ->«  V" 
'r  •'f  '>  't*  'r*  'I*  '1'  'I-  1*  '!•  *t*  »i*  '.•  't*  -.•'I'  'r  ^v  »r  'i»  i*  'i*  'i*  'i*  '.'•  ^  n*  *<* 


J<  ^*o«  Ou  .t-  .U  U.  O* 


The  t;ET_I_AST_Ii\'r^I  Procedure  is  called  "by  th^  Ma>e_ 
I_AST_entry  procedure.  The  procedure  will  sear'^h  the 
I_AST  fron  top  down  until  an  available  index  ic  fnmd. 
If  an  index  is  not  found,  a  success_ccde  of  I_i>ST_full 
is  returned.  If  an  index  is  found,  the  index,  and  a 
success  code  of  valid  are  returned. 


«C  ^t#  kl«  *l«  «l«  «i^  «i«  «!•  .*«  «t«  «f«  »■«  *t«  «I«WU  •!»  •>'«  ^l'  «*>*  «*'  '•■^  *f*  ■A*  ^JU  O*  «'«  ^*  OU  ^<  JU  «i«  «i«  • 

;;;  TJt  5;?  ?^  5,f  I,C  ?,C  5JC  ;,J  ^  ^J  35;  ;^  yg^Tr  n*  '1*  *»"  '»■*  '»*  'f*  1*  '1*  'r*  1*  1*  'i*  t*  '1**1*  -i*  'i*  - 


»  '1*  *n  'I*  '(■«  1*  1*  1*  ' 


GET_I_AST_NO_INDEX  PROCEPURE 

RETURN  f  SUCCESS_CCrE   lYTE  ,  L_IMrEX    '-/ORr^ 

LOCAL    I     '-fORD 

E  N  T  RY 

SUCCESS  _COr^    :=   VALII' 

I    :=   0 

ILOOF:    DC 

IF    I    =>    I_AST_Llr^lT    THEN 

SjCCESS_CCFE    :=   L_AST_FULL 
RETURN 
FI 

IF    I_ASTri]  .rEMf"RY_ALER    =   AVAIIAPLE   THEN 
L_INrEX    :=    I 

L_AST[I]  .N'Er^ORY_ArrR    :=    ACTIVE 
RETURN 
FI 

I  +=  1 
OD 
END  GET  L  AST  NO  INDEI 
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*JU  ,JLm  a,(«  •/«  kt-  tji»  ^L.  af^   fe,ttf   «i«  it>^    ^«  ^1^  *.>^   «L.  «t.   «f^  «JL,  «t«   0«   «*•  «4«  *>**  0«   <kl«   «*'   «''   ^'-  «>U>   «''  •>*«   ^*«  k*>   «'«   0«   «>*  ^*'   ■^''   ^'if  «k*'  «*<•   ^'   •'"  •'-   «*'  «''   «**  «*'  «*'  *^'   •J"  ^>   «*'   ^'  *''  ^*'  ^'^   «''   «** 
^  7^  5,J  ^i  ^[;  ^  ::|C  5JC  XJi  5;*  >,'  5,C  J,t  5,i  JjS  5,1  JjC  5j;  5^1  ;,C  *,♦  5|t  5|C  *,i  ^C  Jr*  'i*  V  'r*  *i*  't*  'i*  'i-  'f  '»'  'i**  'i*  'i*  -i*  'i*  'i-  'i*  'i^  'r  '»'•  •»•  '»••  •"•'  "''■  ''^  'i*  ">*  'r  '»*  'i*  'i*  'i*  '»-  'i* 

*  The  GET_G_AST_INrFX  Procedure  is  called  frorr  the  ^dke_  - 
^'  G_AS'"_entry  procedure.  The  procedure  will  search  the  ^« 
'■•  Ct_AST  from  the  top  down  until  an  available  inde?  is    "^^ 

*  found.  If  an  index  is  not  found,  a  success_code  of     '^•' 

*  G_A?T_full  is  returned.  If  an  index  is  found,  the  index'*' 

*  and  a  success  code  of  valid  are  returned.  '•' 


GET_G_AST_IN'rEX  FROCErURE 

PETU^N       (    S^JCCESS_COEE      BYTE    ,    INDEX        VOFD) 

LOCAL        I        WCRL 

ENTRY 

SUCCESS_rOEE       :=      VALIL 

I    :=   e 

ILOC?:    10 

IF    I    =>   G_i.ST_LI?^IT    TEEN' 

SrCCESS_CGLE    :=    G_AST_FULL 
FET^TFN! 
EI 

IE   G_i>.ST[ll  .UNICUID_ID1    =   N^TLL    THEN 
INLET    :=    I 
RETURN 
EI 

I    +=    1 
OL 
END    GET   G   AST    INDEX 


*  *R*  *!.•  «t»  «■«  «1U  ^1^  ^f  ^*  «JU  "**  V'  ^'^k''  ^''  U*  %>«  k'«  «JU  ^«  •!•  *^«  «*ir  kt^  «V  O^  «l«  •>*«  «l«  %f«  »l«  «1«  «'«  «>«  »t*  »*'  «>•  *lr  «!'  <kf«  «*>  «!'  «t>  *k>«  «*••  *(«  »t'  «*'  «*«  v'*  k''-  «.l^  «t«  «f,  < 

•  ^[*  »|*  *j*  rf*   »|*  *,%  ^*  i"!*  ^i"*  *|«  ■'i*  ^j«*|«  »|»  r^-*   »|^  *■!»  *,•  »|»  *,*  *i*  *|»  «|*  ^1*  *^  >j»  *,^  V|«  *|«  *(*  r|«  *|»  »|»  *(*  »i*  ^»  *j*  '!»  *i»  *,»  »j»  *(*  •"[»  *|*  *,%  *i"»  *f»  •■,»  »|*  »i*  »(■•  »i«  *|*  " 

The  ^^AKE_G_AST_ENT?Y  procedure  is  called  fror  the 
Activate  procedure.  The  procedure  will  obtain  an 
index  irto  the  G_*ST  and  enter  the  aDpropriate  data 
from  the  alia?  talle.  The  fla^  hits  are  set  to  not 
writter  an''  not  writable.  Tne  eventcounts  and  tic^^^et 
fields  are  set  to  zero.  The  proce5Sor_L_ASTE_-«*  fields 
are  set  to  null.  If  the  entry  is  successfully  made, 
a  success  code  of  valid  will  he  returned. 


« 


MAKE_G_AST_ENTR^  FROCEDa^.E  (FAR_INDEX 
RET'T-RNS  (  SUCCES5_CCDE  LYTE,  INDEX 
LOCAL       I       WORD 


'VORD,ENT^.Y_NO 
WORD  ) 


ENTRY 
SUCCESS  CODE,  INDEX 


=  GET  G  AST  ENTRY 
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17    succrss_corE  =  vaiii        them 

G_AST  [IMD::X]  . 'JNIOTJir_IDl    :=   AIIAS_TASIE.  AIIAS_rMT?.Y  F 

SKT^.r_NO]  .Ui\-icuir_ic 

G_A?T[INrE7]  .GIOPAI_Ai:rR    :=    ACTIVE 

G_ASTriMDEX]  .riAG_2ITS    :=   G_AST  [IN  LEX] .ELAG_5ITE 

A  NT    (    NOT      ".\^HITTE,\_MASK    ) 
G_A3TriNrE7] .riAG_ElTS    : =   G_AST [INTEX] .rLAG_rITS 

AND    (    NOT    WHITA3IE_MAS?:    ) 
G   AST  L  INDEX]  .G_ii.STE_NC_FAR    :=  ?AR_IN'DEX 
G~A?T  [IND^X]  .NO_ACTIVE_IN_yEr^OP.Y    :=    i. 
G_^ST  [INDEX] .NO_ACTIVE_DEPSNrENTS    :=    2 
G    AST  [INDEX] .SIZEl    :=   AIIAS_TAEIE. ALIAS_ENTHI [ 

^NTr.Y_NG    ]  .SIZE 
G_AST  riNDEX] .FaGE_TAEIZ_LOCl    :  = 

;LIAS_TAILE.ALIAS_ENTRY[ENTKI_N0] .FAG^_TArLE    ICC 
G_A?^  [INDEX]  .AIIAS_TAIIE_I0C1 :  = 

AIIAS_TA3IE.ALIAS_EMTR^[ENTRY_N0] .AIIAS_TA3IE_I0C 
G   AST[IND^X] .INSTANCE!    :=   0 
G'AS'^riNr^T]  .INSTANCES    :=    0 
G_AST  [INDEX]  .SECUSNCSR    :=    0 
I    :=  e 
ILCO?;   DO 

IF    I    =  NO_OE_??OCESSORS    THEN 

EXIT 
EI 

G_AST  [INDEX]  .?ROCESSORS_I_ASTE_NC[l]     :=    NHII 
I    +=   1 
CD 


SUCCESS    CODE    :=    VALID 


EI 


END    ^^AXE   G    AST    ENTRY 


»  «t*  **«  •X^  %t0  «JU  •■«  *(«  «*'  «>«  «*>  «J'  «JU  %>*  *f«  «*>  «J*  «i*  «*«  »t«  «*«  ■^^  *(<  «*'  «*«  *'*  «''  ^''  ^*'  ^'  ^*'  ^'  ^J'  ^'  ^'  ^*  <^'  «''  ■''  ^''  «*'  ^'^  '^''  ^«  *'«  ■»''  **■  ^''  ■^''  •>''  ^''  ■'''  ^''  ^''  *^'  •'•'  ^'' 

The  ^A^E_I_AST_ENTRY  Procedure  is  called  fron  the  * 

activate  procedure.  The  procedure  will  o"btain  an  * 

index  into  the  I_AST  and  enter  the  apDropriate  data.  =■'• 

*  The  nernory_addr  field  is  set  to  active*  the  sefn',ent_  ■' 

*  #/access_auth  fields  are  initialized  to  zero,  and  * 

*  the  passed  se,£:rrent  numher  is  entered  into  the  ap-  * 
-'  propricte  location.  If  the  entrv  i?  successfully  * 
••'       rrade,  a  succes s_co'1  e  of  valid  is  returned.  * 

VU  «t*  «l^  «JU  «A.  «IU  JU  «!•  ai «  »■>  V«  U*  OU  *>!«  «('  «*«^t«  «■«  •^''  ^  2*"  ^  ^'  o'*  *>*'  ^if  «**  «*''  **«  «*'  ^*  **^  «*'  ^*  ^'  *''•  "J*  '^-  •'^  *'-  •-*'  •■''  *^  -■'''  *^  *'**  ■«'''  «*'  ^'  o^*'  ■«''  '^  •''  *^'  '^''  ^''  -''  '^'  -'^    t 


^AXE_I_AST_ENTRY   PROCEDURE  (LPR_NO   BYTE,  SEG^;ENT_NO 
RETURNS  (  SUCCESS  CODE   FYTE ,  L  INDEX   WORD  ' 


LOCAL   I 


^'fORD  ] 
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SiG    NO         ^^OPD 
ENTRY 
?^JCCZSS_COrE,    L_I\'rE7    :=    Gi:T_L_AST_INrEX 
IF      ?UCC5S?_C0D5   <>    VailL      TFEM  RETURN 

I_ASTri_IMriX] .MZMORI_ArrR    :=    ACTIVE 

I    :=  e 

DO 

T_ASTri_INrEX] .SEGMENT_NO_ACCESS_AUTH[l]     :=    e 

I      *=   1 

IF      I    >=    :^AX_LBR_NO      THE:;        EXIT 

FI 
OL 
I_AST[I_INrEXl  .SEGMENT_N0_ACCESS_rJTH[L3R_N'0]  :  =SEG^'EN'^_riO 
ENT    MAKE    I    A?T    EMTRY 


The   DEA':TIVATE_ALI    Procecure    is    called      ty    the 
De  tete_er.tr:/   Drocedure    and      hy    the    !^ain_line 
procedure.    The   procedure   will    deactivate    the 
deleted    segment    fron^   all    connected    process' 
address    space.    The    G_AST    index   and    the   I_AST 
index   for   the    deleted    se^nent    are    passed    to    th( 
procedure.    If    the   segment   was    successfully 
deactivated    from   all    connected    iDiocesses,    a 
success_code   of   valid   is    returned. 


'I' 


•f«  «JU  ^0  «f«  ^«  «>•  *t«  %Af  *V  ^'  ^'  vA*  ^'  ^'^  ^*«  ^U%'«  ^f'  *''  2'«  *''  ^'  *''  **'  *'*  **'  ***  ^''  ***  **'  *''  *'*  **'  ***  *''  **'  ^'*  *'*  ***  ^'*  *'*  ^'*  *'*  **'  *''  *■**  ^**  *'*  *'*  ^**  *■*'  *'*  ^*'  **'  ^**  *** 

EEACTIVATE_AII      PRCCErURE    (    INDEX      YOPL,    L_rirEX      WOFI    ) 
RETURNS    (    SUCCESS_COrE        BYTE    ) 
lOCAI      I      PYTE 


:ntr^ 

I 
EO 


=   ?. 


THEN 


EXIT 


IF    I    =    ^'AX_rRR_NO 
FI 

IF      L_AST[I_INrEX]  .5EGyiFNT_N0_ACCESS_JiUTF  f  I] 

<>    ZERO      TFFN 
SUCGESS_CO^E    :=    BEACTIVAE    (    I.    INFEX    ) 
IF      SUCCESS_CGrE    <>    SEG_EFACTI VATEF      THEN 

RETURN 
FI 
FI 
I    ^=   1 


CD 


SUCCESS_COrE  :=  VALID 
;mD   DEACTIVATE  AIL 
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J: 


« 


The  SIGiMAI_0THEF._r^EMORT_MA;>IAGEF.  Procedure  is  called 
"by   th'^  Ir  procedure.  The  procedure  will  signal 
a  memory  manas-er  to  move  a  se^rment  from  its  lo^al 
mPT-'ory  to  glotal  memory,  //hen  the  segment  is  moved 
to  p-lobal  memory  the  procedure  will  signal  all  ether 
connected  memory  managers  to  update  their  local 
da^-ahases.  The  glohal  address  for  the  transfer 
is  passed.  A  succes5_code  is  returned  to  indicate 
the  success  of  the  operation. 


signai_otk?:p_mevcry_managef.s   PPCCSDUHE  ( 
spg_indez  wopd,  aecp  .vopp  ) 
eptt^ens  (   success_cope   lyte  ) 

lOCAI 

PRCCES3GR_N0     E^TE 
FIRST       BYTE 
L_ENT?.''_NO    WORD 
VAIir_MSG    BYTE 

M^G         ARRAY  [vAX_r^5G  SIZE   FYTE] 
EMTRT 

FIRST  :=  TRUE 
P^OrE^SOR_NC   :=  C 
DO 

IE   FROCESSGR_MO  =  PROCESSOR_ID    THEN 

?ROCESSOP_NC   +=   1 
FI 
IF   PROCESSOP_NO   >=   NO_OF  PROCESORS   TEEN 

E7IT 
FI 
I_ENTRT_NO  :=  G_AST  [SEG_INrET]  .PROCESS DR_I_A5TE_\0  [ 

PROCFSSOR_ir'  ] 
IE   I_EMTRT_NO   <>   Mill    THEN 
IF   FIRST  =   TRUE     TEEN 
FIRST   :=   FALSE 
IF   PROCESSOR_NO 
CASE   ?    TEEN 

SIGNAL  (  VP_ID.  N'EMORY_MANAGER_?.  vCVZ, 
L_ENTRT_NO,  ADDR  ,  G_A.ST  TSEG.INIEX]  .  S  IZE  ' 
VP_ID,  MSG  :=  WAIT 

!    ***-   CEECK  IF  VALIB   MSG   •-:=--    ' 

VALI^_^'SG  :=  V ALIDATE_¥AIT_MESSaGE  fNSG) 
FI 

ELSE 
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IT   P?OCESSCH_NC 

CASS      ?      THEN 

SIGNAL  (    T7F_ID,    MEMOHY_.^ANAGiIi_f ,    UPrATE, 
L_ENT?Y_NC,    AD"'?.,    &_A^T  lSEG_I  NIEX]  .  ?  I  Z^    ^ 
VF_ir,    MSG    :=   V/AIT 

'*      CFEC?:      IF      YAIir      MSG         ----       ! 

VALir   ^^SG    :=   VAIITATE   WAIT   !^ESS AGEd^SG  ^ 


EI 

EI 

n 

PPOCESSOR  NO 


+= 


OD 


IE  VAIir_N'SG   TFEN' 

SUCCESS_COEE  :=  VAIIL 

SLS^ 

*=;rCCESS_C GEE  :=  INVAIIE 

EI 
END  SIGNAL  OTFE?  MEMOP.T  MANAGEPS 


T«V«  «JU  V#  «(«  •I'  «I«  «J^  ^^  vJ*  »(«  %*'  *ik  ^V  »'«  OI« «(«  *l«  ^«  «l«  &<«  «l«  ^U  ^U  «('  ^1^  «l«  J^  hl«  »*«  >l«  «'*  «1«  >ll« 
^■»  *(•  ^1^  *!«•  rf*   *,*  jij*  r|b  »,*  «|«  rf|*  *,-»  ^^  *|*  o^«  «,*  «|«  ^j«  ^j«  >ft  #|«  ^i»  «,%  ^,*  »|«  »|«  «f«  «|«  »,»  ^«  ^f*  ^|«  ^,<a 


The  CPEATE_EMTHY  Procedure  is  called  hy   the 
'^ain_line  procedure.  The  procedure  will  create 
an  entry  irto  the  alias  table  and  allocate  sec- 
ondary storage  for  the  created  sep-rent.  If  the 
alias  tahle  does  rot  exist,  the  procedure  will 
create  an  alias  taole  on  secondary  storage. 
A  nnique_id  is  assigned  to  the  sefnent  and  the 
appropriate  data  is  entered  into  the  tahle. 
If  the  function  is  successfully  '^orrpleted,  a 
success  code  of  see-nent  created  is  returned. 


;;;  f 


CPE\TE_EN'TPY      PPOCELUPE    (    FAP_I\'DEa      WGRD,    ENTPY_N0      VOPL. 

SIZE      WOPD,    CLASS      2YTE    ) 
(    S'^CCESS    CCEE      lYTE    ^ 


PETT^RNS 
LOCAL 


PAGS_TA5LE_L0C 
PLIS  WORD 


'•/ORE 


ENTRY 
3LKS 


=      SIZE    /   PIr:_SIZE 
IF    G_AST[FAR_IN:^EX]  .G_ASTE_NO_FAP    <>    Z^RO    TREK 

STTCCESS_COrE    :=    CREATE_ALAIS  _TAELE(    FAP_IMEy    ^ 
IE    SaCCESS    CODE    <>    VALID    TFEM 

RETURN    ~ 
EI 
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:nd 


5TTCC5?S_C0D3    :=    F2flI)_A.LIA3_TArIEf 

G_AST  [?AR_INrEX]  .  All  AS_TABIE_L0C1 ,    « All  AS_T  ABU  ) 
IF    ?^'CC?SS_CCLE   <>    VAIir    TFTN 

TI 

ir   ALIAS_TAIIE.AIIAS_ENTRI[ENT?J_i\0]  .UMCUir_ID    ^>    e 

ST^CCESS_COEE    :=    rUPIICATE_ENT?Y 

EI 

PAGE_TAELE_LOC,  SUCCESS_COrE  :=  All  OC_SSC_?TOP.AC-E  ( 

IIK5    ^ 
IE    ?TTCCESS_CODE   <>    VALID  THEN 

RET'JRN 
FI 
AIIAS_TABIE.ALIAS_E^JTPY[E:>ITRY_MO]  .UMlCUE_ir, 

S'JCCESS_CODE    :=    rrET_'TNIC_ir 

IF    ?rccEss_ccrF  <>  valil  tfen 

RETURN 
Fl 

ATIAS_TALPIE.ALIAS_ENTRrrENTRT_KO]  .SIZE    :=    SIZE 
AIIAS_Ta5IE.AIIAS_E.MTRY[EiviTPY_N0]  .CLASS    :=    CLASS 
ALIAS_TAPLE.ALIAS_EKTRYrENTRT_NOl  .FAGE_TAPLE_IOC    :  = 

PAGE_TAILE_LOC 
ALIAS_TAPLE.ALIAS_ENTRy[EN-TR^_NOl  .^LIAS    Ta3I^_L0C    :=    2 
SUCCESS_CODE    :=   WRITE_ALIAS_TABLE (G_ASTTP AR_IKr^X] . 

ALIAS_TAPLE_LCC,    #ALIAS_TAILE    ) 
IF      S7CCESS_C0I;E    =    VAIIL      THEN 
SUrCESS_CODE    :=   SEG_CREJiTEr' 
FI 
C^.EATE    EM  TRY 


f  ::t:;j 


* 
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«i«  tju  »i*  J*  ^*  J,  *ju  »», »»,  »i,  »i,  »i^  ^^  ,t*  J*  »»,  »i,  u«  •»*  v*  '••■■  V*  •'•  ^'-  ***  *''  *•'■•  *''  *•-  *■'*  *'*  *'tf  ***  **'  i!r  s!;  **-'  ili  ;'i  i*;  3*;  ;':  y;  ;'c  ;*;  y;  ^c  ;*;  i*;  sis  y;  ;' j  ;Ic  ;':  yc  ;*i  yc  5l^  5'c  f 

rTLFTT_SN'TFY   PRCCErUH"  (  PA?._IMr5:7   WCEr  ,  E.MTF-Y_NC   WCFT  ' 
HETIT^.WS  (  SUCCESS_COrE   BYTE  ) 
LOCAI   I_INI:EX   word 
INIEy    WORT 
I      BYTE 

AIIAS_TAELE_EMP?Y    BYTE 
OTFERS_ACTIVF       BYTE 
ENTRY 

IF   C-_AST  [FAR_Ii\DEX]  .ALIA5_TABLE_I0C1    ^>    NUII      THEN 

?ncCESS_CODF    :=   REAr_AI  AI  S_TABI.E    (    G_AST  [PAF^I  NTEX]  . 
AIIAS_TABIE_L0C1,    #ALIAS_TABI^    ) 
ELSE 

?aCCESS_COrE    :=    NO_CFII.r_TO_rELETE 
FI 

IF  snccEss_corE    <>    valid    then 

RET'JP.M 
FI 

AIIAS_TA?.IE_^MPTY    :=    CHECK:_IF_ALIAS_E^^PTY 
IF      AIIA?_TABLF_E.^?TY    =    TRUE      THEN 

STJCCE?S_CODE,    IMDET    :=    SEARCn_G_AST    ( 

AIIAS_T«BLE.ALIAS_ENTRYlEi\TRY_i\0]  .UMC'tE_ID    ) 
IF      ?TTCCFSS_COrE    =    FOUND      THEN 

I_INDSX    :=   G_AST[PAR_INDEX1 .PR0CE£S0RS_1_ASTE_N0[ 

PROCESSOR_ID] 
IF      I_INrEX    <^>    NULL      THEN 

STJCCESS_CODE    :=   DE4CT  IVATE_AII  ( INDEX,    I_INrE7) 
IF      SUCCESS_CODE    <>    VALID      THEN 

RETURN 
FI 
FI 

0'^FERS_ACTIVF    :=    CHECK_IF_OTFERS_ACTIVE 
IF      OTHEPS_ACTIVE    =    TR^TE         THEN 

S IGNAL_OTFERS_TO_DEACTIVATE_ALL 
FI 
FI 

DEIETE_SEG     (    ENTRY_NO    ) 

AIIA5_TABIE.AIIAS_ENTRTrENTRl_Nj]  .UNICUE_ID    :=    Q 
SUCCESS_CODE    :=   'rfRITE_\LI A^_TABIE    f    G_AST rPAR_I ND^Xl . 

ALIAS_TABLS_LnCl,    t^AL  I.AS_TAI-IE    ) 
IF      S^TCCESS_CODF    =    VALID      THEN 

?UCCESS_CODE    :=    SEG_DEiETED 
FI 
EI!^E 

SUCCESS_CODE    :=    DEt=ENDENT?_EXIST 
FI 
END      DETETF   ENTRY 
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I  ;V  ***  ;**  ;*c  ^'  J*j  5*'  ?*t  5*t  **t  5*'  ;*?  ;*i  j'c  *'» jV  >"'  5*c  **;  ^i  ?*;  j'c  /;  rf;  j*?  j*c  5!c  5*c  ?'c  ^t  Jli  ?'^  J**  **;  ^  5*;  ;Ss  5**  5*c  j'c  5*i  ^c  "''  ? »  5  »  ?*;  ^a  ^c  j'c  j*?  **t  5*'  ?'*  j*i  ?'■;  r't  5*;  5'-  sic 
5];  *•• 

*  The  ACTIVATT  Procedure  is  called  ty  the  ^ain_line  - 

*  procedure.  The  purpose  of  activate  is  to  add  a  --^ 

*  sej?ment  to  the  user's  address  space.  The  procedure  '■= 

*  is  passed  the  5egiT!ent_# ,  the  parent's  handle,  and  * 

*  the  entry  numher  into  the  alias  tahle  for  the  '•' 

*  seernent.  The  prc^edure  returns  the  size,  * 

*  class.,  and  the  handle  for  the  activated  segment  * 

*  The  C-_'l?T  is  searched  to  deterrnine  if  the  segr°rt  * 

*  is  already  active.  If  the  seernent  is  active  and  * 
not  in  the  I_AST,  an  entry  i<:  made  in  the  I_AST  * 
and  the  C-_A?T  is  updated.  If  the  segrrent  is  active  '•' 
in  hoth  the  G_AST  and  the  L_AST.  the  entries  are  * 
updated.  If  the  segment  was  not  active,  entries  * 

*  are  rrade  in  hoth  the  G_AST  and  the  I_AST.  * 

*  If  the  operation  was  successfully  completed,  a  * 

*  success_code  of  seg_activated  is  reti:rned.  * 

*^£  2^  ^f  ^  ^  ^  *''«  ^  ^  ^Jl*  *»*'  ^o  *<A«  ^  «*'  «V  ^V  «*«  ^'^  i^  «*'•  ^  o)^  •"'  ^'"A.  Up  U*  (J*  «.*«  -./«  o«  %f«  %t*  «t«  «f«  U..  «i^  a..  «J-  .,1,  «o  -U*  <Ji*  vi«  «J«  «•«  ^«  ^<  %!'  ^>  «*•  «•«  »•-  «<«  «•<  «t*  «f'    t 
A*  ^1*  'I*  '^  T^  'I*  1*     1^  *1^  'I*  'I*  O*  *^  'I*  '***!*  *!*  I*  •!*  *^^  '»*  *l*  ^t^  *i^  'l*  *!*  *i*  't*  *!*  1**1*   'I*  *l*  '(*  't*  *!*  1*  *!*  '**  f*   '**  'f*  *l*  'i*  *!*  *I*  '1*  *l*  *1*  *!*  'l*  'l^  'l*  'I*  'l^  '»*  'I*  *l*     I 

ACTIVATE        P?.OCSDURE    (EP?_N'0      BYTE,    PA?_INDEa      WO^E, 

ENT?.I_NO      VOP.r,    SEGMENT_NO      rTTE    ) 
P.ET^TPM^       (    STTCCES?_COrE      lYTE    ,    G_AST_HANriE      FAfslIIE    . 

CLASS      P'^TE,    SIZE        WOPD    'I 
lOCAI      I_INrEX        VORP 

I  MP EI  WOEI 

EMTPT 
IE    G_AST[PAR_INPEX]  .ALIAS_TAPIE_I0C1       <'>      ZEiO         THE^' 
SrcCESS_CCrE    :=   PEAr_ALIAS_'!^AII.E''G_AST  [PAR_IN'PEX]  . 

ALIAS_TA5IE_L3ri  .    #AII Ar_TAPIE ) 
ELSE 

SnCCESS_CCPE    :=   NC_LEAE    EXIST 
EI 
IE   S7CCESS_C0r'E   <>   VALIP      THEN 

FET^PM 
EI 
STTCCESS_COPE    ,    INPEX    :=    SEAPCr:_G_AST    ( 

AL  I  AS  _T  APL  F  .  AL I  AS  _E  M  TP  Y  [E  N  T  R  Y  _  N  0]  .  U  K I C  U  ^  _  I P  ^ 
IF      S7CCSSS_C0EE      =      FO;TND        THEN 

L_INPEX    :=   G_AST[IKPEX]  .PROCSSSORS_L_ii.ST^    i\0[ 

PPOCESSOP_irT 
IF      L_IMPEX      <^      NULL         THEN 

L_AST[L_INPEX] .SEGMENT_NO_ACCESS_AUTH[PBR_N0]     := 

SEGN'ENT.NC 
ELSE 

SUCCESS_COPE,    L_INPEX    :=    ^A?:E_L_AST_ENTPY    ( 

rPR_NO,    SEGrEMT_NO    ") 
IF      S'JCCSSS_COPS      ^>      ^AIID      THEM 

RETURN 
FI 


12S 


G    'V'^T'riNrEX]  .^'HOCES^JOT^S    I_ASTF_NO  [^FCCFSFOR_ir] 
~         "  :=      L'lMCIX 

FI 
IP      C-_ASTriNrFX]  .ALIAS_TAPI5^_L0C1    =    NULL      TEE^i 

G_AST  [PAR_IMDEX]  .M0_DEPFMDEiMT5_ACTIVi      -=      1 
FI 
FISF 
^   S7CC5SS_C0i:S,    IfJLFI    :=   MAIF_G_AST_3:MTP.Y(  F^JT?.Y_NO) 

IP    srccEss_coD=:  =  g_ast_puli    tffn 

PFTTTPN 
FI 
SUCCFSS_CODF.    L_IN'DEX    :=   ^AKE_I_AST_INT?T    ( 

PAR_INrEX.    ENTRI_NO    > 
IF      5lTCCESS_C0rE   =    L_AST_FUII      THEN 

RETURN 
FI 

G_^STriN'I)EX]  .PR0CESS0R3_L_ASTE_N'0  [P-CCESSOF_ir]     : 

I_  INDEX 
FI 

SUCCESS_CO^E    :=    ?EG_ACTIVATEr 

SIZE       :=   AIIAS_T;BLE.ALIAS_EKTt=^[ENTRT_NO]  .SIZE 
CIAS?     :=   AI.IAS_TaBLE.AIIAS_E.\'TPY[EMTRI_NO]  .CLASS 
G_AST_HANDIE.UNICUE_ID2    :=G_AST  [INDEX]  .UN  ICTJE_IL1 
G_AST_FANrLE.INrEX    :=    INDEX 
'ND      ACTIV.«iTF 


t  %••  2*; '«'(  y^  y«  ;*^  ;■'  2*;  «*;  y^  **t  ^^^  7^t  ^^ 


The  SVA?_OUT  Procedure  is  caller^  "by  the  r^ain_lir,e 
procedure  or  the  Deactivate  procedure.   The 
procedure  will  rerove  a  sef?ment  from  main  memory 
drr\    store  it  on  secondary  storage.  The  procedure 
is  passed  the  pro'-ess'  DiR_#  and  the  G_AST  index 
for  the  segment  to  he  swapped  out  of  memory. 
A  succes5_code  is  returned  to  indicate  the  success 
of  the  operation.  The  prcedure  removes  the 
segment  from  the  process'  '^MU_Ima,?e  and  if  not 
shared »  it  is  returned  to  secondary  storage 
and  memory  deallocated.  Shared  serments  remain  in 
memory  until  all  processes  have  swapped  the  segment 
out  of  main  memory. 

■  «*«  ^t«  ^«  ^*  «f«  »>«  «(« 

.  ,,^  ^IP»  ,f^  ,^  ,^■>  ,p,  *,» 

SWA?_OUT      PROCSD^TRE    (    DrR_NO      BYTE,    INDEX      >;ORD 
RFT^TRNS    f    SUCCrsS_CODE      PYTE    ) 
lOCAI        PIKS      WORD 

1_ INDEX      WORD 

SPG    MO         WORD 


* 
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ENTFY 

2IES    :=  G_AST[INEETl  .SIZ:h:i    /   3I?:_SIZE 

I_INDEX:=G_AST[INrEX]  .  FROCESSOR_L_ASTE_NO  [FHnc?SSOP._  ID] 

SEG_MO    :=   I_\ST[L_IMr'E7]  .3EGMEN'T_N0_ACCESS_AUTH  [rF?_NOj 

EFEE_^^OCESS_VIP.TUAL_CORE    (    ELKS    ) 

DEIETE_M'^U_ENTRI    (    DEP_NO,    SEG_i\0    ) 

G_AST[IMrEl]  .NO_ACTIVE_IN    MEl^OHY    -=    1 

IF    (MMTJ_IMAGE[DBR_N01  .SDRrSEG_NO]  .ATTRIBUTES      AND 

WRITTEN_MASK)    <>    Q         TFEN 
G_AST[nrEI]  .EIAG_IITS    :  =   G_AST  [INTEy]  .  EI  A^-_PITS    OR 

WRITTEN■_^'ASK 
EI 
IE      G_ASTriNEEX] .GLOPAI_ArDR    =    NULL      TFEN 

IF      G_fl.STriNDE7] .NO_ACTIVE_IN_ME^ORY    =    Z      ANEIE 

(G_AST  [INDEX]  .FLAG_BITS    AND    VRITTEN_MASK )    <>    ?. 
TFEN 

SUCCESS_CODE    :=   WRITE_SEGMENT    (    G_AS T [INDEX] . 

FAGS_TAPLE_LOC»    L_A?T [L_I NDEX]  . 
MEMCRY_ADDR    1 
IF    SUCCESS_CODE   <>   VALID      TFEN 

RETURN 
EI 

FREE_LOCAL_PIT_MA?    f    I_AST  [L_INDEX]  .^'EMORY_ADDP  , 

PIK?     ) 
EI  ?E 

IE      G_flST  [INDEX]  .NO_ACTIVE_IN_MEMOPY    =    2      TFEN 
EREE_LOCAL_EIT_MAF    (    L_AST [L_INDEX] . 

yEMORY_ADDP,    PLKS    1 
EI 
EI 
EL^E 

IE      G_AST  [INDEX]  .NO_ACTIVE_IN_^^E'^ORY    =    ?      ANDIE 
(G_AST [INDEX] .ELAG_EITS    AND    WRITTEN_MASK )    ^>    0    TFEN 
?UCCESS_COrE    :=   WPITE_SEGMENT    (    G   AST  [INDEX]. 

PAGE_TAPLE_L0C1,    G_AST [INDEXj . GI05AL_ADDR    ) 
IE      SUCCESS    CODE    <r>   VALID      TFEN 

RETURN 
EI 

ERES_GLCBAL_BIT_MAP    (    G_AST [INDEX] . GLODAL_ALDR  , 

BIKS    ^ 
ELSE 

IE   G_AST[INDEX]  .NO_ACTIVE_IN_r^EMORY  =  €   THEN 
EREE_GLCIAL_BIT_MAP^  G  AST [INDEX]  .GLOBAL_ADDR  . 

3LKS    } 
-EI 
EI 
EI 

SUCCESS_CODE    :=    S'VA?FED_OUT 
END    SWA?   OUT 
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*  The  DEACTIVATE  Procedure   is  called  bv   the  * 

*  the  Main_lir.e  prc^edure,  the  r'eactivdte_dll  * 

*  procedure,  or  the  Delete_entry  procedure.  * 

*  The  purpose  of  deactivate  is  to  remove  a  se^rnent  * 

*  frorr  a  process'  address  space.  The  segment  is  '•• 

*  removed  by  deleting  the  segment  number  from  the  * 

*  L_AST.  If  no  other  processes  have  th'=  segment  * 

*  active  and  no  children  are  active,  the  entry  * 

*  is  removed  from  the  L_AST  and  the  G_A3T.  * 

*  The  process'  EBR_#  and  the  deactivated  segment's  * 

*  G_.AST  index  are  passed  to  the  procedure.  A  * 

*  success_code  is  returned  to  indicate  the  success  * 

*  of  the  operation.  * 

•I*  "i- 

«i«  «i«  a*  JU  •■•  tju  <kf:«  gu  «.u  u*  *i*  «*>  o«  v  ^*  v«>tf^  u*  «i«  >j^  -J-  «u  «»»  vu  «u  «^  a«  ^^^  ^  ju  a*  *u  ^^  «i«  «,i*  y^  a«  ^u  <,>.  ^«  o^  <j*  «u  «g  «;.  u«  «>«  *>.  «u  «r«  ^^  «t,  ..i,  ju,  .i«  «v  ^^  v.-  ^  t 

^fi  *l*  *,»  »!■»  vy*  #1*  »j»  *|»  *-|*  <r|^  *,»  •-,■.  #)%  y^t  •,*  #|*«|«  'I*  n*  "T*  1*  *!*  '»■■  *•*  ^*  1*  T*  I'  ^  •*•  '•■*  '<^  'l^  '•*      •        '      ''■■     '      '•"*  't*  "^^  '•*  '»*  '•*  ***  '1*  't*  '•*  T*  'l*  'l*  ""I*  "t"  *t*  *»*  '•     'I*  *1*  T"     I 

DEACTIVATE      PROCEDURE    (    DLR_NO      BITE,    INDEX      "i^CRD    ) 
RETURNS       (    SUCCESS_COrE      xYTE    ) 
LOCAL        L_INDEX        WORD 

SEG_NO  BITE    > 

CHECK  BYTE 

PAR_LMDEX      WORD 
ENTRY 
PAR_INrET    :=   G_AST[INDEX] .G_ASTE_NO_PAR 


IN_MEi^ORY    MASK)    =    Z^:R0         TF 
SUCCES3_C0DE    :=   S\vAF_CuT    T   DBR_NO,    INIEX    ) 
IF      SUCCESS_CODE   <>   SWAFPED_OUT         THEN 

RETURN 
II 


EI 

FI 


I_A?T[I_INDEX] .SE&MENT_NO_ACCESS_AUTH[DBR_NO] 

CHECK    :=   ACTIVE_IN_L_AST(    L_INDEJ    ) 

IF      CHECK    =   0      THEN 

I_A?T[L_INDE7J  .MEMCRY_ADrR    ;=    AVAILABLE 

FI 

IF      PAR_INDEX      <>    0      THEN 

G_AST[PAR_INrEX]  .N0_ACTIVE_DEFENDENTS    -=    1 
CHECK_FOR_REMOVAI    (    ?AR_INLEX    ) 

FI 

CHECK_FCR  REMOVAL  (  INDEX  ) 

?UCCESS_CODE  :=  SEG_DEACTIVATED 
END  DEACTIVATE 
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-  e 


_^ -_ . -- ._-.-  --  _^-_ --  -_ -,  --  ,_  --  --  --  --     -- -  __,_  __  ._ ._  ,___  __  fc'rf  ^*  ^«  «IU  *<*  ^* 

«-^  ^«  ^^  ^l«  «l*  «,«  ■■|«  ^|«  *}«  ^«  «^«  '|%  ^|«  1«  «f>  ^1*  ^|«  ^|«  «][«  ^|«  «!«  «)«  '^«  'I*  *|«  r,^  '|«  '^  ','«  >)^  '4'«  »|«  *l*    'i^  '(*  #1^  ^l*  «|*  ^«  ^«  1*  «|«  'i*  ^%  «|«  '|«  ^,*  'I*  «|«  '|«  «|«  ^1^ 

«  * 

*  The  MO?E_TO_GLOPAL  Procedure  is  called  by  the  * 

*  Mdin_line  procedure.  The  procedure  is  called  to  * 

*  to  move  a  shared  and  writable  segrnent  to  ^lolal  * 

*  memory.  The  procedure  is  passed  the  L_AST  index,  * 

*  the  size»  and  the  global  address  for  the  move.  * 

*  A  success_code  is  returned  to  indicate  the  * 

*  success  of  the  operation.  The  procedure  locates  * 

*  the  se,?ment  in  its  local  memory,  transfers  the  * 

*  segment  to  global  memory,  and  deallocates  the  * 

*  local  memory.  * 

*  * 

«l«  «■«  *fM  **#  **«  «*«  •*«  %*«  »'•  «t«  «*«  •'«  «•«  *■«  «««  k1««fa  *l#  «**  •fi  •'^  *f*  «*«  «*«  «■#  «*•  •*>•  ^'*  V^  «K#  oJ^  «f«  «l#  «l>«  «>'  «t«  ^*  ^«  ^«  ^l«  V«  tj^  s,l^  «'»  kl^  «>*  %li>  «t«  «*#  «t«  U«  %••  «l«  «,*«  «t«  «l«  «)«  «l«  «■«    I 
»4*  •«•  »!•  *(■•  •»•  •■,*  *i«  •!•  ',•  »!•  »,»  •(•  '|**|«  »,»  •»•*»•  •»»  *!•*!*  •!•  *|»  'I*  *!•  'i»  '|*  •(•  f  *ll*  '|*»  'l* '**  'I*  *!*'!•  "l"*  '»"•  'l*  '|-  'i*  "f*  'i*  'i^*  'C  •(*  1*  'l''  'i-  'l'  'i'  '(*  'l*  'i»  ^"^   ';■»  I'*  •»■•  'i»  '•"     T 

MOVE_TO   GLOBAL      PHOCirURE    (    L_INLEX      WCRD,    GLOPAL_ArLn 

ADDRESS,    SIZE        WORD    ) 
RETURNS    (    srCCESS_CODE      x^ITE    ) 
LOCAL  SEG_NO        PYTE 

I  BYTE 

ENTRY 
MEMORY_N"OVE    (    L_AST[L_INrEX]  .MEr^ORY_ArDR,    GLCIAL    ADLR, 

SIZE    )" 
L_AST[L_INDEX]  .ME.^.ORY_ADDR      :=      ACTIVE 
I    :=  e 
DO 

IP      I    =    MAX_DPR_NO      THEN        EXIT 

PI 

SEG_NO    :=   L_ASTrL_INDEX]  .SEGr^ENT_NO_ACCESS_AUTF[I] 

AND      %( 2) 01111111 
IF      SEG_NO    <>    e      ANDIP      ( !^MU_IMAGE  [I]  .  SPR  [SEG_NO]  . 
ATTRIBUTES    AND    I N _n"E r<OR Y_MA SK  )    =    ?      THEN 
MMU_IMAGE[I] .SDR[SEG_NO] .FASE_ADDR    :=    GLOBAL    ADDR 
FI 
I    +=    1 

PREE_lGCAL_BlT_MAr    (    L_AST  [LI  NEEX]  .MEyiORY_ADLR  .    BLKS     ) 
SUCCESS_CODE    :=    VALID 
END      ^^0V    TO   GLOBAL 
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«  «l«  ^«  ^«  *■«  ^«  OU  **#  aJ. 


«*«  «•«  »V  «'«  ••-  *••  «■«  »'-  »•*  ••*  •*«  »i«  «i.  *•*  «t«  «'•«••  ♦»*   *'-  •■•*  **'  •*-  »'-  Jrf  *l*  *•-  *•'  ***  *•*  ***  ***  ***  *'■•  ^  *•*  •'•  *•"  *'"  •'*  *'*  V'  **'  »'*  «'*  **■•  *'*  •••  V-*  *'■•  »''  ••'  •'*  *•*  •'*  ^'*  *'*  *•*  •■•'•  *'■•     f 

•»■•  '•'  •■»*  »i*  *!*  *»•  »»•  •••  •■»•  '»•  ",*  »»•  'i*  •»•  ',■  *«»»i*  '»*  1*  '■*  •**  '**  "I*  'I*  'r*  1*  'i'  'I*  'I*  "i*  'I*  'P  'I'  *t*  'I'  'i«  '1*  'i*  'i*  *(•  '»•  *i»  'i*  -p  ',»  'c  'i»  '!•  *.*  ***  -(-  »,■•  'I-  »,-•  ^1*  ',»  -i»  '1-  '('    I 

SWAP    IN    PHOCErURidNrFX    WOHE,rBR_MO      LIT?,  ACC£SS_AUTE      EITE  ) 
RETURNS    (    SUCCESS_COLS      E^TE    ) 
LOCAL      ELKS      WORC, 
TEST      PYTE 
SEG_NO      BYTE 
L_Ii\T'EX      WORD 
LASE_ADrR      ADDRESS 
EM TRY  ~ 

5LK3":=   G_AST[ INDEX] .SIZE    /   BLK_SIZE 

L_IN'DEX  :=C-_AST  [INDEX]  .FROCESSOR_L_ASTE_NO  [?ROCESSO?_ID] 
SEG_NO  :=  L_AST[L_IMDEX]  .  SEGi^:E,MT_iMO_ACCSSS_AUTH  [DDP_NC] 
STTCCSSS_CODE  :=  CFECK_MAa_VIRTUAL_CORE  (  DER_NO,  BLKS  ) 
IE      SUCCESS_CODE   =   VIRTUAL_CORE    FULL         T^'EN 

RETURN 
FI 

G_ASTriNDEX]  .NO_ACTIVE_IN_ME?^ORY      +=    1 
IF      ACCESS_AUTK   =   WRITE      TEEM 

G   AST  [INDEX] .FLAG    BITS    :=    G_AST [INDEX] .ELAG_iITS    CR 

<vRlTAIDI_r^ASK 
FI 

IF      (G_AST  [INDEX]  .FLAG_BITS    AND   VR  ITABLS_i^AS?:  }    =   C 
OFIF    G_AST[IMDEX]  .\'0_ACTI7E_IN    ^EMOPY    <=    1       THEN 
TEST     :=   CHECL'_LOCAL_MEr^ORY"(    L_INDEX    ) 
IF      TEST    <>    IN_LOCAL_^Ei^ORY      TFEN 

5UCCESS_C0DE,BASE_ADDR    :=   ALLCC_LOCAI_vEyGRY ( ILKS ) 
IF      SUCCESS    CODE    =   LOCAL_ME>'ORY_FULL      THEN 
RETURN 

n 

SUCCESS_CODE    :=    READ_SEGMENT    (    G_AST [INLFX] . 

FAGE_TABLE_LGC1,    iASE_ADD-     ) 
IF      SUCCESS_CODE   <>    VALID      THEN 

FREE_LOCAL_BIT_r^AF    (    BASE_ADDR,    EIHS    ) 

RETURN 
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I_ASTrL_INrFX]  .(^EMOHY_AriR    :=   IASF_ArrR 
EISE 

PAS^_ADrR    :=    L_AST  [L_r NDEX]  .  ME,^0?.Y_ADDR 

n 

ELSE 

IF      G_AST [INDEX] .GICBAL_ADrR    =    NULL      TKEM 

SjCCESS_COrE,    iASE_ArrR     :=   ALLOC_GLOrAL_^iSMOHY^ 

EIKS    ) 
IF      SUCCESS    CODE   =   GLOBAL_MEMORY_FULL      THEN' 

RETURN 
FI 
IF      TEST    =    IN_LOCAL      THEN 

SUCCESS_COEE    :=  MCVE_TO_GLOIAL    (    I_INDEX, 

5ASE_ArD^.,G_A£T  [INDEX]  .SIZEl^ 
IF   SUCCESS_CODE   <>   VALID      THEN 

FREE_GLOIAI_EIT_^^A?    (    IASE_ADrR,    ILKS    ) 
RETUPN 
FI 
ELSE 

SUCCSSS_CODS  := 

SIGNAL_GTHER_MEMORY_yiANAGERS(  INDEX, EASE    ADDR  ) 
IF      SUCCESS_CCDE   <'>   VALID      THEN 

RETURN 
FI 
FI 
ELSE 

PASE_ADDH    :=   G_AST [I NDEX] .GLORAL_ADDR 

FI 

UFDATE_MMU_IMAGE(DBR_NO,  SEG_NO,  3ASE_ADDR,  ACCE£S_AUTE, 

BLKS  ) 

u?date_l_ast_access  (  l_index,  a.ccess_auth,  ri?_nc  ) 
succes5_c0de  :=  swapped_in 
:nd  swap  in 


*  The  ^'OVE_TO_LOCAL  Procedure  is  cdlled  ly  the  '^ain_  -- 

*  line  procedure.  The  procedure  is  called  when  * 

*  a  seerrent  no  longer  needs  to  he  in  ^lohal  rrerrory  * 

*  and  can  he  moved  to  local  memory.  The  procedure  * 

*  is  passed  the  L_AST  index,  size,  and  glohal  address  '•' 

*  of  the  segment  to  te  moved.  A  succes5_code  is  returned  ''■' 

*  to  indicate  the  success  of  the  operation.  -•' 

'!»  •.•• 

«f«  «l>  «t«  «t*  V'  *^  «*'  *f»  «''  **«  ^*  «*'  ^*  «''  **'  «''  ^'  •*'  *"*  ^'  »**  iJ#  ij*  «*«  *l«  «*«  «4#  sf»  «V  «*«  kli*  «'^  mJU  »I«  */«  «'«  «^*  vi*  *l«  0«  s)«  O*  «td  ^«  *t«  «'«  «l^  «t«  <»*«  0>  «<«  «l.  «)^  «•«  ^t*  «>'  «*'  «Ji*  %*«  V 

r^OVE_TO_LOCAI      PROCEDURE    (    L_INDEX      a'ORD,    GLOrAL_ArDR 

ADDRESS,      SIZE      WCRI    ^ 


134 


1-7         \ 


I'-ETU^NS    (    S7CC2SS    CODT:      3TTi    ; 
LOCAL        PASS_ADrR^SS  ADDHFS5 

SFG_\'0  PYTE 

I  BYTE 

ELKS  BYTE 

ENTP.Y 

BLKS  :=  SIZE  /  BLK_SIZE 

SUCCESS_COr'E,    BASE_ACrRESS    :=    AILOC_LOC AL_MEMOFY(  ILrCS  ; 
IF      srCCESS_COrE   <>   VALIL      THEN 

RETURN 
FI 

MEMCRY_^^OVE    (    GLOBAL_ArrR.    BAS7_ArLRESS  ,    SIZE    > 
L_AST[L_INDEX] .mE^ORY_ALDR    :=   BASE_ADDRESS 
I    :=    ? 

ro 

IF      I    =   >^Aa_DBR_NO      then      EXIT 
FI 

SEC-_NO    :=    L_AST[L_INBEX]  .SEC-MENT_NO_ACCESS_AUTF[l] 
AND      !?^(2)?1111111 
IF    SEG_NO    <>    e    ANFIF    (MMa_IMAGE [l]  .SDR rSEG_NO]  . 

ATTBIBUTES   ANT    IN    [^E^ORT    MASKl    =    Q      TEEN 
^'^^a_I^!AGE[I]  .SLRi;SEG_N0l.BASE_AI)LR:=3A£E    ACE^.ESS 
FI 

I    +=    1 
OD 

success _code  =  valid 
:nd    p^ove  to  local 


a. 

'I* 

*  The  update  Procedure  is  called  ly  the  r^ain_line 
'■'  procedure.  The  procedure  is  called  to  update  the 

*  MMU  imait-es  of  process'  connected  to  a  sep-ment 

*  that  was  moved  tc  global  memory  by  the  Mo ve_ to_^lol:al 

*  procedure.  The  procedure  is  passed  the  L_AST  irdex, 

*  the  size,  and  the  ^lotal  address  of  the  segment 

*  that  was  moved  to  f^lchal  address.  A  succes5_code 

*  is  returned  to  indicate  the  success  of  the  operation. 
■J, 


UPDATE   PROCEDURE  (  I  INDEX   WORDt  GlOIAL_ADrR   ADIPESS, 

SIZE    WORD  ) 
RETURNS  (  sncCEbS_CODE    BYTE  ) 
LOCAL   SEG_NO    BYTE 
BLKS     B^TE 
I       BYTE 
ENTRY 
I  :=  2 
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DO 

IF   I  =  MAX_DEK_NO    TFEN     EXIT 

71 

SEG_N'0    :=   L_AST[L_IMDSX]  .SEGMrNT_^JC_ACCESS_Anrr:  [Ij 

AND      %{2)eillllll 
IF      SSC-_NO    <>    e      ANIir    (i^i'^,U_I^'AGE[I]  .SrH[SEG_NC]  . 
ATTFIBUTES    AND    IN_MEMORY_MASr: )    =    0      THEN' 
MMU_IMAGS[I]  .SDH[S5G_N0]  .BASE_ACDR    :=    GLGIAL_ArDR 
EI 

I    +=    1 
OD 

ELK?    :=    SIZE    /   ILK    SIZE 

F^EE_IOC'lI_BIT    MA?r   L_AS'r[L_INEEJ]  .ME>^ORY_ADrF,    BLKS    ) 
I_ASTrL_INDEX]TMEMCRY_ADDR    :=    ACTIVE 
SUCCESS    CODE    :=   VAIIP 


E^JD    UPDATE 


MAIN    LINE      CODE  >:c*=;^*=;c         i 

^SECTION    VAIN 

?^AIN_IINE      PROCEDURE 

LOCAL        FUNCTION      lYTE 

ARGUMENTS    ARRAY    [    ???      B^TS] 
MSG  ARRAY    [V|AX_MSG_S  IZE      BYTE] 

VP_ID  PYTE 

SUCCESS_CODE   BYTE 
ENTRY 
INITIALIZE_PR0CESS0R_L0CAL_VARIAFLFS 
DO 

CHECK_MSG_CUEUE 
V?_ID,    MSG    :=   '*'AIT 

I         '^^'i^*      VALIDATE      THE      MSG      FROM       J/AIT      '-'^''^  i 

FUNCTION,    ARGUMENTS    :=   VALIDATE_MSG    (    MSG    ) 
IF      FUNCTION 

CASS   CPSATE_ENTRY      THEN      SUCCESS_CODZ    := 

CREATE_SNTRY(ARG:jMEr'TS) 

case  delets_fntry  then  success_code  := 

delete_entry(apg;'MEnts) 
case  activate  teen  success_c ode , handle, class ,s izf 

activate  (ARGUf^ENTS> 
CASE  deactivate     THEN   SUCCESS_CODE  := 

DEACTIVATE (ARGUMENTS ) 

case  svap_in  then     SUCCESS_CCDE   := 

SWAP    IN(ARGUME.MTS  ) 
CASE    S'iAP    OUT  THEN      SUCCESS_CODE    :  = 

S'VAP    CUT(ARGUMFNTS) 
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CkSn    ^07E    TO    LOCAL    THEN    SUCCESS    CODE    := 

~      ~  M07S_T0_L0CAL(ftRSUMENTS  ) 

CASE   MCVE_TC_CLO£AL    TEEN    SUCCESS_COrE    := 

MO¥E_TO_GLOBAL  (  AT^GUMEinITS  ) 
CASE  UPDATE  THEN    SUCCESS_CODE    := 

UP DATE (ARGUMENTS) 
CASE    DEACTIVAE_AIL    THEN    SUCCESS_CODS    := 

DSACT I VATE_ALL( ARGUMENTS ; 
EL 

SLGNAL    (    VP_LD,    SUCCESS_CODE ,    ARGTTMENTS    ) 
OD 
END    MALN_LLNE 
END   MEMORY   MANAGER   PLZ    SYS    MODULE 
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APPENDIX  B  -  PLZ/ASM  SOURCE  LISTINGS 


!   THE  PLZ/ASM  MODULE  WAS  WRITTEN  TO  PROVIDE  SUPPORT  FOR 
!   THE  SWAP_IN  THREAD  [APPENDIX  3].  TEE  VALIDITY  OF  THE 
I   CODE  HAS  NOT  BEEN  THOROUGHLY  TESTED,  NOR  HAS  IT  BEEN 
OPTIMIZED.  THE  CODE  SIMULATES  SECONDARY  STORAGE  IN 
MAIN  MEMORY,  AND  WAS  MOT  INTENDED  TO  BE  USED  IN  AN 
ACTUAL  SYSTEM  IMPLEMENTATION. 


M  MGR  2  MODULE 


«  * 


VERS,  i.e 


«  « 


CONSTANT 


FALSE 

;  = 

0 

TRUE 

;  = 

1 

AVAILABLE         : 

= 

0   1  AST  ENTRY 

AVAILABLE  I 

ACTIVE 

;  = 

1   !  AST  ENTRY 

ACTIVE  ! 

ZERO 

,= 

2) 

NULL             : 

,= 

%0000 

NULL  PAGE         ; 

;  = 

0 

HBUG              : 

;  = 

%A900 

MONITOR           : 

= 

%059A 

I     SUCCESS  COI 

}Ei 

3    I 

INVALID           : 

= 

0 

VALID 

;  = 

1 

FOUND 

;  = 

2 

NOT  FOUND 

:  = 

3 

SWAPPED  IN        : 

;  = 

4 

SWAPPED  OUT 

:  = 

5 

SEG  ACTIVATED 

;  = 

6 

SEG  DEACTIVATED   : 

,= 

7 

SEG  CREATED 

;  = 

e 

SEG  DELETED       : 

'  = 

9 

LEAF  SEG  EXISTS   . 

;  = 

10 

NO  LEAF  EXISTS 

;  = 

11 

G  AST  FULL 

;  = 

12 

L  AST  FULL        i 

J  = 

13 

IN  LOCAL  MEMORY 

:  = 

14 

NOT  IN  LOCAL  MEM  • 

;  = 

15 

LOCAL  MEMORY  FULL 

:  = 

16 

GLOBAL  MEM  FULL 

;  = 

17 

VIRTUAL  CORE  FULL 

:  = 

18 

DUPLICATE  ENTRY   : 

;  = 

19 

i3e 


NO_CHILD  TO_DEI 
SEC  STOR'FULL 
DISK_EHROR 
ALIAS  DCES_NOT 

ATTRIBUTE  MASKS 
READ  MASK 
WRITE_MASK 
CHANGED  MASK 
IN_MEMORY  MASK 
CLEARED 

AUTHORIZED  ACCESS 
READ 
WRITE 
EXECUTE 


=  20 
=  21 
=  22 


EXIST 
f 


:=  23 


=  %(2)11111110 
=  %(2)00002001 
=  %(2)01000000 
=  %(2)03000100 

=  0 
I 

=  0 
=  1 
=  ^(2)00001000 


!  CLEAR  ATTR  ! 


G_AST   FLAG  BITS  FIELD  MASKS    ! 

WRITAPLE  MASK     :=  %(2)00000010 
WRITTEN_MASK      :=  %(2)00000100 


TYPE 


DESIGN   PARAMETERS 
BLK  SIZE 
MAX  PAGE_SIZE 
NO_OF_PROCESSORS 
MAX_DER_NO 
G_AST  LIMIT 
L_AST  LIMIT 
MAX  ENTRY  NO 
NO  SEG  DESC_REG 
FSf  POSS  FREE_BLK 
DISK_MEM  BASE 
MAX  P0S3_D_ELKS 
GLOBAL  MEM_BASE 
MAX  POSS  G_BLKS 
LOCAL  MEM_BASE 
MAX_POSS  L_BLKS 
r.ISK_EIT_MAP_LOC 

ADDRESS 
ALIAS  HEADER 
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BLK 

1 

4 

16 

16 

10 


SIZE/2 


NO.  OF  DBR_#'S  I 
MAX  ENTRIES  IN  G_AST  ! 
MAX  ENTRIES  IN  L  AST  ! 
SIZE  OF  ALIAS  TABLE  I 

SEGMENT/PROCESS! 


!  EVEN 

! 

I 

i 

!  NO.  OF 


=  1 

=  %9fce0 

:  96 

■-   %a000 

=  32 

=  %6000 
:  64 
=  0 

WORD 
RECORD  [ 

seg  page  table_loc 
?ar"alias  table  LOC 


WORD 
WORD  ] 


SEG  DESC  REG 


ALIAS 


RECORD  [ 
BASE  ADDR 
LIMIT 
ATTRIBUTE 

RECORD  [ 
UNIQUE_ID 
CLASS 
SIZE 


ADDRESS 
BYTE 
BYTE  1 


WORD 
WORD 
WORD 
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page  table  ioc  word 
aliaS_tabl5_loc  word  ] 

mmu  record  [ 

sdr  array     [no  seg  desc_reg 

seg_desc_reg] 
3lks  used  word 

max_blks  word] 

GLOBAL 

!$SECTION   G_DATA   ! 

GLOBAL_MEM   BIT    MAP  ARRAY    [MAX_P0SS    G_BLKS/16   WORD] 
G_AST_L0CK"        "  BYTE 

!  ^SECTION  L_DATA   ! 

MMU_ IMAGE  ARRAY    [MAX    DBR    NO      MMU] 

LOCAL    MEM_3IT_MAP      ARRAY    [MAX_P0S5_L_BLKS/1 6  WORD] 
ALIAS'TABLE  record    [    HEADER        ALIAS.EEADER 

ALIAS_ENTRY      ARRAY 
[MAX_ENTRY    no      ALIAS]    ] 
DISK    BIT    MAP    BUEE        ARRAY    [6        BYTE] 
PAGE'TABLE   buffer        ARRAY    [BLK_SIZE        BYTE] 
INTERNAL 

COMPACT   L      PROCEDURE 

ENTRY 
END   COMPACT   L 


COMPACT_G      PROCEDURE 

ENTRY 
END   COMPACT.G 

GLOBAL 

ALLOC_LOCAL_MEMORY      PROCEDURE 

f     wyC  ifi  ij/i  39*  *^  39*  'I*  ^i^  JJC  nfm  ^*  ttjfr  ^|*  ^C  Tfi  tff>  ^JC  *f%  ^jfr  ^«  SijC  3|C  9i|«  «f»  ^^  3|C  2yC  '|*  5|S  *|«  #|C  3|«  r^  ^|«  9|«  ^^  «yC  3^  #1%     I 

I  PASSED  PARAMETER 

!    R0  =  BLKS  OF  MEMORY 

1  RETURNED  PARAMETERS 

I    R0  =  SUCCESS  CODE 

!    Rl  =  BASE.ADDR 

!  LOCAL  VARIABLES 

!    R0  =  BLKS 

!    R10  =  BIT  MAP_INDEX 

I    Rll  =  COUNTER  FOR  BIT 

!    R12  =  BIT  MAP  WORD 

!    R13  =  WORKING  REGISTER 
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LOCAL   BLKS   WORD 

IS  COMPACTED   BYTE 
FILLER2    BYTE 
ENTRY 

LD   ELKS,  R0 

LD3   IS_COMPACTED,  #FALSE 
LE   R10,  #ZERO 
DO 

CP   R10,  #(MAX  P0SS_L_3LKS/16) 
IF   EQ   THEN 

CPB   IS  COMPACTED,  #FALSE 
IF   EQ  "then 

CALL  COMPACT  L 
LD   R10,  #ZERO 
LD3   IS_COMPACTED,  #TRUE 
ELSE 

LD   R0,  #LOCAL  MEMORY  FULL 
RET 
FI 
FI 

LD   Rll,  #ZERO 

LD   R12,  L0CAL_MEM_BIT  MAP(R10) 
DO 

BIT   R12,  Rll 
IF   Z   TEEN 

DEC   R0,  #1 
ELSE 

LD   R0,  BLKS 
FI 

CP   R0,  #ZERO 
IF   EQ    THEN 
LD   Rl,  R10 
MULT   RR0,  #16 
ADD   Rl,  Rll 
SUB   Rl,  BLKS 
MULT   RR0.  #3LK_SIZE 
ADD   Rl,  #LOCAL_MEM  BASE 
LD   R0,  #VALID 
LD   R13,  BLKS 


DO 


LD   R12,  LOCAL_MEM_BIT  MAP(R10) 
DO 

SET   H12,  Rll 

DEC   R13,  #1 

DEC   Rll,  #1 

CP   R13,  #ZERO 

IF   EQ   THEN 

LD   LOCAL_MEM  BIT.MAP (R10 ) ,  R12 
RET 

FI 
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ENL 


OD 
INC 

OD 

ALLOC 


n 

INC 

CP 

IF 


CP   Rll,  #ZERO 
IF   EQ   THEN 

LD   LOCAL  MEM  BIT_MAP  (R10  ) ,  B.l^ 

LD   Rll,  #15 

DEC   R10,  #1 

EXIT 
FI 


OD 


OD 


Rll,  #1 
Rll,  #16 
EQ  THEN 
LD  Rll, 
EXIT 


FI 
R10,  #1 
LOCAL  MEMORY 


#ZERO 


FREE_LOCAL_BIT_MAP   PROCEDURE 

1  PASSED  PARAMETERS 

!    R0  =  BASE  ADDR 

!    Rl  =  BLKS" 

I  LOCAL  VARIABLES 

!    R10  =  COUNTER  FOR  BIT  RESET 

!    Rll  =  BIT  MAP  INDEX 

!   r12  =  bit  map  word 
'entry 

CLR   R10 

LD   Rll,  R0 

SU^   Rll,  #LOCAL  MEM  BASE 

DIV      RR10,    #BLK   SIZE*16 

DO 

LD   R12,  LOCAL_MEM_BIT  MAP(Rll) 
DO 

RES   R12,  R10 
DEC   Rl,  #1 
CP   Rl,  #ZERO 
IF   LT   THEN 

LD   L0CAL_MEM_3IT_MAP(R11) ,  R12 
RET 
FI 

INC  R10,  #1 
CP  R10,  #16 
IF   EQ   THEN 

LD   LOCAL_MEM  BIT  MAP{R11),  R12 
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LD      R10,    #ZERO 
EXIT 
FI 
OD 

INC      Rll,    #1 
OD 
END   EREE   LOCAL    BIT    MAP 


FREE_GLOBAL_BIT_MAP      PROCEDURE 

^ioi:  ^  lie  ^  4c :{(:}:  >ie  4:  ^c  ^  J,*:  »;«;;«:;:>;:  4:  >;:  s;c  ^  alt  $;c  3;:  3^ :{(;}:  ^  ^  ^  :^  ;ic  4c :{:  )!c  :je  9i:  ^ic  :^ 

PASSED   PARAMETERS 

R0    =    BASE   ADDR 

Rl    =   BLKS 
LOCAL    VARIABLES 

R10   =    COUNTER  FOR   BIT   RESET 

Rll    =   BIT    MAP    INDEX 

R12   =   BIT    MAP   WORD 

4: 4c  4c  4e>ic  4:  3}c)ic  4:  9ic  4: 9}:  4c  $  4:  s^c :;:  4: 4;  4: 4: 4c  4:  jje  sit  4c  4:  $;:  4c  4: 4: 4:  sic  4c :{: «[( ^  4c  Xc 

ENTRY 

CLR     Rie 

LD      Rll,    R0 

SUB      Rll,    #GL0BAL_MEM_3ASE 

DIV      RRie,    #BL£   SIZE*16 

DO 

LD      R12,    GLOBAL   MEM_BIT   MAP(Rll) 
DO 

RES      R12,    R10 
DEC      Rl,    #1 
CP      El,    #ZERO 
IE      LT      THEN 

LD   GLOBAL  MEM  BIT_MAP( Rll } ,  R12 
RET 
FI 

INC  R10,  #1 
CP  R10,  #16 
IF      EQ      THEN 

LD      GLOBAL   MEM    BIT   MAP(Rll),    R12 
LD      Rie,    #ZERO 
EXIT 
FI 
OD 

INC      Rll,    #1 
OD 
END   FREE   GLOBAL   BIT    MAP 
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ALLOC_GLOBAL_MEMORT   PROCEDURE 

I  PASSED  PARAMETER  ! 

!    R0  =  BLKS  OF  MEMORY 

1  RETURNED  PARAMETERS 

!    R0  =  SUCCESS  CODE 

!    Rl  =  BASE  ADDR 

!  LOCAL  VARIABLES 

!    R0  =  BLKS 

I    R10  =  BIT_MAP  INDEX 

!    Rll  =  COUNTER  FOR  BIT 

!    R12  =  BIT  MAP  WORD 

!    R13  =  WORKING  REGISTER 

LOCAL   BLKS   VORD 

IS_COM?ACTED   BYTE 

FILLERS    BYTE 
ENTRY 

LD   BLKS,  R0 

LDE   IS  COMPACTED,  #FALSE 
LD   R10,  #ZERO 


DO 


CP   R10,  #(MAX  POSS_G  BLKS/16) 
IF   EQ   THEN 

CPB   IS  COMPACTED,  #FALSE 
IF   EQ   THEN 

CALL  COMPACT_G 
LD   R10,  #ZERO 
LDB   IS_COMPACTED,  #TRUE 
ELSE 

LD   R0,  #GLOBAL_MEM_FULL 
RET 
FI 
FI 

LD   Rll,  #ZERO 

LD   R12,  GLOBAL_MEM_BIT  MAP(R10) 
DO 

BIT   R12,  Rll 
IF   Z   THEN 

DEC   R0,  #1 
ELSE 

LD   R0,  BLKS 
FI 

CP   R0,  #ZERO 
IF   EQ    THEN 
LD   Rl,  R10 
MULT   RR0,  #16 
ADD   Rl,  Rll 
SUB   Rl,  BLKS 
MULT   RR0,  #BLK  SIZE 
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OD 

INC 


ADD   Rl,  #GLOBAL_MEM  BASE 
LD   R0,  #VALID 
ID   R13,  BLKS 
DO 


LD 

R12 

,  GLOEAL_MEM_EIT_MAP(R10) 

DO 

SET 

R12,  Rll 

DEC 

R13,  #1 

DEC 

Rll,  #1 

CP 

R13,  #ZERO 

IF 

EQ   TEEN 

LD  GLOBAL  MEM  BIT  MAP(R10), 

R12 

RET 

FI 

CP 

Rll,  #ZERO 

IF 

EQ   THEN 

LD   GLOBAL_MEM  BIT_MAP (R10 ) ,  R12 
LD   Rll,  #15 
DEC   R10,  #1 
EXIT 


FI 


OD 


OD 


OD 
FI 

INC  Rll,  #1 
CP  Rll,  #16 
IF   EQ   THEN 

LD   Rll,  #ZERO 

EXIT 
FI 

R10,  #1 


END  ALLOC  GLOBAL  MEMORY 


READ_PAGE   PROCEDURE 

I  PASSED  PARAMETERS 

I  R0  =  BLK  NO 

!  Rl  =  BASE  ADDR 

!  RETURNED  PARAMETER 

I  R0  =  SUCCESS  CODE 

!  LOCAL  VARIABLES 

!  R10  =  COUNTER  FOR  BLOCK  MOVE 

I  Rll  =  SIMULATED  DISK  ADDRESS 

ENTRY 

LDL   RR10,  #BLK  SIZE 

MULT   PR13,  R0 

ADD   Rll,  #DISK  MEM  BASE 
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LD   R10,  #MAX  PAGE_SIZE 
LDIR      (?R1,    QRil,   R10 
LD   R0,  #VALID 
END   READ  PAGE 


WRITE_?AGE   PROCEDURE 

PASSED  PARAMETERS 

R0  *  BL5_N0 

Rl  =  EROM_BASS_ADDR 
RETURNED  PARAMETR 

R0  =  SUCCESS  CODE 
LOCAL  VARIABLES 

R10  =  COUNTER  FOR  BLOCK  r^OVE 

Rll  =  SIMULATED  DISK  ADDRESS        ! 

ENTRY 

LDL      RR10,    #BLI   SIZE 
MULT   RR10,  R0 
ADD   Rll,  #DISK  MEM  BASE 
LD   R10,  #MAX_PAGE  SIZE 
LDIR   GRll,  ORl,  R10 
LD   R0,  #VALID 
END   WRITE_PAGE 

READ_SEGMENT   PROCEDURE 

PASSED  PARAMETERS  ! 

R0  =  PAGE  TABLE_LOC  (BLK_#)  I 

Rl  =  MEMORT_ADDR  I 

RETURNED  PARAMETER  ! 

R0  =  SUCCESS  CODE  ! 

LOCAL  VARIABLES  I 

R2  =  INDEX  FOR  PAGE_TABLE_ARRAT  ! 

R10  =  COUNT  FOR  BLOCK  MOVE  I 

Rll  =  DISK  BLK_#  CONV  TO  MEM  ADDR  ! 

R13  =  DISK  ADDRESS  ! 

>Jt  ***  sje  jje  *  ;}c  p"^  jjs  j}:  *  ^  s^  sj:  sit  *  :^  jje  jIt  ?;«  ^*  3^  ^:{e:{s:;i*}!t4:  sis  3;e  *:;::!:***  j 

ENTRY 

LDL   RR10,  #BLK_SIZE 

MULT  RR10,  R0 

ADD      Rll,    #DISK_MEM_BASE 

LD      R2,    #ZEPO 

DO 

LD   R10,  #MAX_PAGE  SIZE 

LD   R13,  R11(R2) 

MULT   RR12,  #BLK_SIZE 

ADD   R13,  #DISK_MEM_BASE 

LDIR   0R1,  @R13,  R10 

INC   R2,  #1 
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CP      E2,    #MAX    PAGE.SIZE 
IF      EQ      THEN 

EXIT 
FI 

ID   R0,  R11(R2) 
CP  R0,  #ZERO 
IF   EQ   THEN 

EXIT 
FI 
OD 

LD   R0,  #VALID 
END  READ  SEGMENT 


V<RITE_SEGMFNT      PROCEDURE 

i  PASSED  PARAMETERS 

!    R0  =  PAGE_TABLE_LOC  (ELK  #) 

!    Rl  =  MEMORT_ADDR 

!  RETURNED  PARAMETER 

I    R0  =  SUCCESS  CODE 

!  LOCAL  VARIABLES 

I    R10  =  PAGE  TABLE  ARRAY  INDEX 

!    Rll  =  DISK  BLK  NO  CONV  TO  MEM  ADDR 

!    R13  =  DISK  ADDR  ! 

ENTRY 

LDL   RR10,  #BLK  SIZE 

MULT  RR10,  R0 

ADD   Rll,  #DISK_MEM_BASE 

LD   R2,  #ZERO 


END 


DO 

LD 

R10,  #MAX  PAGE  SIZE 

LD   R13,  R11(R2) 

MULT   RR12,  #BLK  SIZE 

ADD   R13,  #DISK  MEM  BASE 

LDIR   QR13,  0R1,  R10 

INC   R2,  #1 

CP   R2,  #MAX  PAGE  SIZE 

IF   EQ   THEN 

EXIT 

FI 

LD   R0,  R11(R2) 

CP  R0,  #ZERO 

IF   EQ   TEEN 

EXIT 

FI 

OD 

LD 

R0,  #VALID 

WRITE  SEGMENT 
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READ  DISK  BIT  MAP   PROCEDURE 

I  5f:>;sji:s;jj;cJS>;«**»S**««*««* ****** *************** 

!  RETURNED  PARAMETERS 
R0  =  SUCCESS  CODE 
LOCAL  VARIABLES 

R10  =  DISK  BIT  MAP_BUFF  ADDR 
Rll  =  COUNTER  FOR  BLK  MOVE 
R13  =  BIT  MAP  DISK  ADDR 

:i:*:^*****:i::ie*9^*;;(9;c*^*;ic*:{;**:(t**»!e>ic*:ic**;ic****** 

ENTRY 

LD      R10,    #DISK    BIT_MAP 
LD      R13,    #DISK   BIT_MAP_LOC 
CLR    R12 

MULT   RR12,  #BLK  SIZE 
ADD   R13,  #DISK  MEM  BASE 
LD   Rll,  #(MAX_P0SS"D_BLKS/16) 
LDIR      3R13,    GR10,    Rll 
LD   R0,  #7ALID 
END   READ_DISK_EIT_MAP 

WRITE_DISK_BIT_MAP   PROCEDURE 

1********************^****************** 

I  RETURNED  PARAMETER 

!    R0  =  SUCCESS  CODE 

!  LOCAL  VARIABLES 

!    R10  =  DISK  BIT_MAP_BUEF  ADDR 

!    Rll  =  COUNTER  FOR  BIT  MAP 

!    R13  =  BIT  MAP  ADDRESS 

I  * ***;;c^}i:*>;:^:;«:f(};:3ic ****};::{: :ic:ie*:{:*;^*:;:**^^* >{:>;(* s;:?;::;; 

ENTRY 

LD   R10,  #DISK_BIT_MAP 
LD   R13,  #DISK  BIT  MAP_LOC 
CLR  R12 

MULT   RR12,  #BLK_SIZE 
ADD   R13,  #EISK  MEM  BASE 
LD   Rll,  #(MAX  P0SSID_BLKS/16) 
LDIR   GR10,  GR13,  Rll 
LD   R0,  #VALID 
END   WRITE_DISK_BIT_MAP 

SEARCH  DISK  BIT_MAP   PROCEDURE 

PASSED  PARAMETER 

R0  =  START_SRCH_BLK_# 
RETURNED  PARAMETERS 

R0  =  SUCCE3S_C0DE 

Rl  =  FREE  BLK  # 
LOCAL  VARIABLES 

R10  =  BIT  COUNTER 

Rll  =  BIT  MAP  INDEX 

R12  =  BIT  MAP  WORD 
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'entry 

CLE   R10 
LD   Rll,  R0 
DIV   RR10,  #16 
I   R10  =  REM,   Rll  =  QUOT     ! 
DO 

LD   R12,  DISK  BIT  MAP(Rll) 
DO 

BIT   R12,  R10 
IF   Z   THEN 

SET   R12,  R10 

LD   DISK_BIT_MAP(R11),  R12 
LD   Rl.  Rll 
MULT   RR0,  #16 
ADD   Rl,  R10 
LD   R0,  #VALID 
RET 
FI 

INC  R10,  #1 
CP  R10,  #16 
IF   EQ   THEN 

LD   R10,  #ZERO 
EXIT 
FI 
OD 

INC   Rll,  #1 

CP   Rll,  #(MAX  P0SS_D_BLKS/16) 
IF   SQ   THEN 

LD   R0,  #SEC_ST0R_FULL 
RET 
FI 
OD 

LD   R0,  #VALID 
END   SEARCH  DISK  BIT  MAP 


CLEAR_DISK_BIT_MAP   PROCEDURE 

>!t5:**sj:*i;!*3;s*sis*>!:*5;:****st:5;!*5!s sis******* ********  » 

PASSED  PARAMETER 

R0  =  BLK  NO  TO  CLEAR 
LOCAL  VARIABLES 

R10  =  BIT  COUNTER 

Rll  =  BIT  MAP  INDEX 

R12  =  BIT  MAP  WORD 

*********************************:;:****; 

ENTRY 
CLR   R10 
LD   Rll,  R0 
DIV   RR10,  #16 
!   R10  =  REM,  Rll  =  QUOT   ! 


14:9 


LD   R12,  DISK  BIT_MAP(R11) 
RES   R12,  R10 

LD   DISK_BIT_MAP(R11) ,  R12 
END   CLEAR  DISK  BIT  MAP 


MEMORY  MOVE   PROCEDURE 

!  PASSED  PARAMETERS 
!     R0  =  TO  ADLR 
!     Rl  =  FROM  ADDR 
I     R2  =  SIZS'IN  BYTES 

ENTRY 
CLR   R12 
LD   R13,  R2 
RR   R13,  #1 
LD   R12,  R0 
LDIRB   0R12,  ORl,  R13 
END   MEMORY  MOVE 


GET_UNIQ_ID   PROCEDURE 

!  RETURNED  PARAMETERS  ! 

I     M    =  SUCCESS  CODE  I 

I     Rl  =  UNIQUE  ID  I 

!  NOTE:  WILL  BE  STORED  ON  SEC  STOR       ! 

LOCAL   WORK  SPACE_BLK   ARRAY  [MAX  PAGE  SIZE   WORD] 

UNIQ  ID   WORD 
ENTRY 

LD   R0,   #SYSTEM_DATA  LOC 
LD   Rl,   #WORK  SPACE_BLK 
CALL  READ_?AGE 
CP   R0,  #VALID 
IF   NE   THEN 

RET 
FI 

LD   R10,  #ZSRO   !  UNIQ_ID  INDEX  ! 
LD   R13,  WORK_SPACE_BLK(R10) 
LD   UNIQ_ID,  R13 
INC   R13,  #1 

LD   WORK_S?ACE  BLK(R10),  R13 
LD   R0,  #SYSTEM  DATA_LOC 
LD   Rl,  #WORK_SPACE  BLK 
CALL  WRITE.PAGE 
LD   Rl,  UN!q_ID 
END   GET_UNIQ_ID 
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MAIN_LINE   PROCEDURE 

ENTRY 

CALL  ALLOC_LOCAL  MEMORY 

CALL  BBUG 
END  MAIN_LINE 
END  M  MGR  2 
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APPENDIX  C  -  SVAP.IN  PLZ/ASM  CODE 

MEM_MGR  MODULE 

I    «  «  «  «    VERS.  1.0    «  «  *  *   I 


CONSTANT 

FALSE            : 

;  = 

0 

TRUE             ! 

«  = 

1 

AVAILABLE         : 

;  = 

0   !  AST  ENT 

ACTIVE           : 

,= 

1   I  AST  ENT 

ZERO             : 

;  = 

0 

NULL             : 

= 

^0000 

NULL  PAGE         : 

;  = 

0 

HBUG"            ; 

;  = 

%A900 

MONITOR           : 

:= 

%059A 

!     SUCCESS  COI 

)E^ 

3    I 

INVALID 

;  = 

0 

VALID             ! 

•s 

1 

FOUND             ! 

•  =: 

2 

NOT  FOUND 

;  = 

3 

SWAPPED  IN 

!  = 

4 

SWAPPED  OUT      : 

= 

5 

SEG  ACTIVATED 

;  = 

6  ■ 

SEG  DEACTIVATED   . 

;  = 

7 

SEG  CREATED 

;  = 

8 

SEG'DELETED 

;  = 

9 

LEAF  SEG  EXISTS   ' 

;  = 

10 

NO  LEAF  EXISTS    : 

= 

11 

G  AST  FULL 

;  = 

12 

L  AST  FULL 

;  = 

13 

IN  LOCAL  MEMORY   : 

= 

14 

NOT  IN  LOCAL  MEM 

;  = 

15 

LOCAL  MEMORY  FULL 

;  = 

16 

GLOBAL  MEM  FULL   - 

;  = 

17 

VIRTUAL  CORE  FULL 

:  = 

18 

DUPLICATE  ENTRY 

;=: 

19 

NO  CHILD  TO  DEL   ! 

J  = 

20 

SEC  stor'full 

;  = 

21 

DISK  ERROR 

;=: 

22 

ALIAS_DOES_NOT_EX] 

[S' 

r   :=  23 

!     ATTRIBUTE  MASKS     ! 

READ  MASK         : 

1  — 

%(2)11111110 

WRITE  MASK        : 

,= 

%(2)00000001 

AVAIUBLE    ! 
ACTIVE    ! 
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CHANGED_MASK 
IN_MEMORY  MASK 
CLEARED 
AUTHORIZED  ACCESS 
READ 
WRITE 
EXECUTE 


=  %(2)01000000 
=  %(2)00000100 

=  0 
J 

=  0 
=  1 
=  %(2)00001000 


I  CLEAR  ATTR  ! 


G_AST   FLAG  BITS  FIELD  MASKS    ! 

WRITABLE  MASK     :=  %(2)00ee0ei0 
WRITTEN  MASK      :=  %(2)00000100 


DESIGN   PARAMETERS 
ELK_SIZE 

NO  OF  PROCESSORS 
MAX  DBR  NO 
G_AST_LIMIT 
L_AST  LIMIT 
MAX  ENTRY  NO 
NO_SEG_DESC_REG 
FST  POSS  FREE  BLK 


126 
1 
4 
16 

16 
21 
8 
1 


I  EVEN  NO.  OF  D3R_#'S  ! 
I  MAX  ENTRIES  IN  G_AST  1 
!  MAX  ENTRIES  IN  L_AST  ! 
I  SIZE  OF  ALIAS  TABLE  I 
NO.  OF  SEGMENT/PROCESS  I 


TYPE 


ADDRESS 
ALIAS  HEADER 


SEG  DESC  REG 


ALIAS 


WORD 

RECORD  [ 

SEG_PAGE_TABLE_LOC   WORD 
PAR  ALIAS_TABLE_LOC  WORD  ] 


RECORD  [ 
BASE_ADDR 
LIMIT 
ATTRIBUTE 


ADDRESS 
BYTE 
BYTE  ] 


RECORD  [ 
UNIQUE  ID 
CLASS 
SIZE 

PAGE  TABLE  LOC 
ALIAS  TABLE  LOC 


WORD 
WORD 
WORD 
WORD 
WORD 


MMU 


G  AST  REC 


RECORD  [ 
SDR  ARRAY 

BLKS  USED 
MAX  BLKS 


[no  seg  desc  reg 
seg_desc_regJ 

WORD 
WORD] 


RECORD  [ 
UNIQUE  IDl 
GLOBAL_ADDR 
!  ONLY  ONE  PROCESSOR  I 


WORD 
ADDRESS 
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L  AST  REC 


HANDLE 


PROCESSORS  L  ASTE_NO   WORD 
!  WRITTEN  BIT  AND  WRITABLE  BIT  ! 
ELAa_BITS       WORD 
G_ASTE  NO  PAR     WORD 
NO_ACTIVE  IN_MEMORT   WORD 
NO_ACTIVE  DEPENDENTS   WORD 
PAGE  TABLE  LOCI   WORD 
SIZEl      '      WORD 
ALIAS  TABLE_L0C1  WORD 
SEQUENCER      WORD 
INSTANCEl       WORD 
INSTANCE2       WORD  ] 

RECORD    [ 

MEMORT.ADDR  ADDRESS 
SEGMENT_NO   ACCESS_AUTH   ARRAY 

[MAX.DBR  NO        BYTE]    ] 

RECORD  [ 

UNIQUE_ID2  WORD 

H  INDEX  WORD  ] 


GLOBAL 

!$SECTION      G_DATA      ! 


G.AST  ARRAY    [G    AST    LIMIT      G_AST_REC] 

G_AST    LOCI  BYTE 

DISK   BIT    MAP    LOCK      BYTE 


I    ^SECTION   L_DATA      I 


EXTERNAL 


MMU  IMAGE 
L_AST 
ALIAS  TABLE 


ARRAY    [MAX_DBR    NO      MMU] 
ARRAY    [L_AST   LIMIT      L_AST_REC] 
RECORD    [   HEADER        ALIAS.HEADER 
ALIAS    ENTRY      ARRAY 
[MAX_ENTRY_N0      ALIAS]    ] 
DISK    BIT    MAP   BUFF        ARRAY    [6        BYTE] 
PAGE    TABLE_BUFFER        ARRAY    [BLK    SIZE        BYTE] 


ALLOC  LOCAL  MEMORY   PROCEDURE 

ENTRY 
END  ALLOC  LOCAL  MEMORY 


READ_SEGMENT   PROCEDURE 

ENTRY 
END  READ  SEGMENT 
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free  local_bit_map    procedure 

Intrt 
end  free  local  bit  map 


ALLOC  (}LOBAL_MEMORT   PROCEDURE 

ENTRT 
END  ALLOC  GLOBAL  MEMORY 


M0VE_T0_GL03AL   PROCEDURE 

ENTRY 
END  MOVE_TO_GLOBAL 

SIGNAL_OTHER_MEMORY  MANAGERS   PROCEDURE 

ENTRY 
END  SIGNAL_OTHER_MEMORY_MANAGERS 

INTERNAL 

UPDATE_MMU_ IMAGE    PROCEDURE 

PASSED  PARAMETERS 

R0  =  DBR  # 

Rl  =  SEGMENT  # 

R2  =  ADDR    "  I 

R3  =  ACCESS  ! 

R4  =  LIMIT  ! 

LOCAL  VARIABLES  ! 

R10  =  WORKING  REGISTER  ! 

R13  =  WORKING  REGISTER  ! 

ENTRY 

LD   R10,  #MMU  IMAGE 

LD   R13,  #SIZEOF  MMU 

MULT   RR12,  R0 

ADD   R10,  R13 

LD   R13,  #SIZEOF  SSG_DESC_REG 

MULT   RR12,  Rl 

ADD   R10,  R13 

LD   OR10,  R2 

INC   R10,  #2 

LDB   3R10,  RL4 

INC   R10,  #1 

LDB   RL4,  OR10 

CPB   RL3,  #EXECUTE 

IF   EQ   THEN 

ANDB   RL4,  #%( 2 )11110111 
ELSE 

ANDB   RL4,  #%(2 )11111110 
FI 
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ORB      RL4,    RL3 
LDB   GR10,  RL4 
RET 
END  UPDATE  MMU  IMAGE 


UPDATE  L  AST_ACCESS    PROCEDURE 

!  PASSED  PARAMETERS 
R0  =  INDEX 
Rl  =  ACCESS  AUTH 
R2  =  D3R  # 
LOCAL  VARIABLES 

R5  =  WORKING  REGISTER 
R7  =  WORKING  REGISTER 

sje  *  J:  s^  *  «  *  :i£  *  *  s}e  s}t  *  >;«  «  *  sle  5!{ «  *  *  «  # :;{ *  *  sje ;;« >;« «  *  ;;e «  *  J}:  ;;e  *  * 


ENTRY 

LD 

R5, 

#L  AST 

LD 

R7. 

#S!ZE0F  L  AST  REC 

MULT   RR6,  R0 

ADD 

R7, 

#2 

ADD 

R7. 

R2 

ADD 

R5, 

R7 

LDB 

RL3 

.  GR5 

CP3 

RLl 

,  #WRITE 

IF 

EQ 

THEN 

ORB 

RL3,  #%(2)10000000 

LDB 

GR5,  RL3 

ELSE 

ANDB 

RL3,  #%(2)01111111 

LDB 

GR5,  RL3 

EI 

RET 

UPDATE  L 

AST  ACCESS 

END 

CHECK  LOCAL_MEMORT   PROCEDURE 

9{:  $  3;:  >;c  ^  j^c)}: :{:  3f :{:  >r  ^  »^  n(  n(  nC  nt  n:  >ic  >!( 'S' >!<  ^  4= »!:  ^  sje  ^  >!<  n:  9>(  ^  >i' n^  >{(  ^  >{(  ^ 

PASSED  PARAMETERS 

R0  =  INDEX 
RETURNED  PARAMETER 

R0  =  TEST 
LOCAL  VARIABLES 

R2  =  I 

R3  =  SEG  NO 

RH3  =  ATTRIBUTES 

R10    =   ADDR    OF    MMU_IMAGE.SDR[SEG#1 

Rll    =   ADDR    OF    L   AST  [R3]  .SEG/ACC [I] 

R12,13   =   WORKING   REGISTERS 

ENTRY 
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LD   R2,  #ZEHO 
DO 

CP   R2,  #MAX  DBR_NO 
IF   EQ   THEN 

LD   R0,  #NOT  IN  LOCAL  MEM 
RET 
FI 

LD   Rll,  #L_AST 
LD   R13,  #SIZEOF  L_AST_REC 
MULT   RR12,  R0 
ADD   Rll,  R13 

ADD   Rll,  #2   1  SEGMENT  NO  OFFSET  I 
ADD   Rll,  R2 
LDB   RL3,  GRll 
CLRB   RH3 

ANDB   RL3,  %(2)01111111 
CPB   RL3,  #ZERO 
IF   NE   TEEN 

LD   R10,  #MMU  IMAGE 

LD   R13,  #SIZEOF  MMU 

MULT   RR12,  R2 

ADD   R10,  R13 

ADD   R10,  R3 

ADD   R10,  #3     !  ATTRIBUTES  OFFSET  ! 

LDB   REl,  ORie 

ANDB   RHl,  #IN_MEMORY  MASK 

CPB   RHl,  #ZERO 

IF   NS   TEEN 

LD  R0,  #IN_LOCAL  MEMORT 
RET 
FI 
FI 

INC   R2,  #1 
OD 

END  CHECK  LOCAL  MEMORT 


CHSCK_MAX_VIRTUAL_CORE   PROCEDURE 

!   PASSED  PARAMETERS  ! 

R0  =  DBR  #  I 

Rl  =  BLKS  ! 

RETURNED  PARAMETER  ! 

R0  =  SUCCESS  CODE  I 

LOCAL  VARIABLES  I 

R10,R12  =  WORKING  REGISTERS  ! 

ENTRY 

LD   R10,  #MMU  IMAGE 

LD   R13,  #SIZEOF  MMU 
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MULT   RR12.  R0 

ADD 

R10, 

R13 

LD 

R13, 

#SIZEOF  SEG  DESC 

REG 

MULT   RR12,  #N0  SEG  DESC  REG 

ADD 

R10, 

R13 

LD 

R12, 

GR10 

ADD 

R12, 

Rl 

INC 

R10, 

#2 

CP 

R12, 

GR10 

IF 

GT   THEN 

SUB 

R12,  Rl 

LD   R0,  #VIRTUAL  CORE 

FULL 

ELSE 

LD   R0,  #VALID 

FI 

DEC 

R10, 

#2 

LD 

GR10, 

R12 

RET 

CBECK  MAX 

VIRTUAL  CORE 

END 

SWAP_IN   PROCEDURE 

!  PASSED  PARAMETERS 

!  R0  =  INDEX 

I  Rl  =  DER_# 

I  R2  =  ACCESS 

!  RETURNED  PARAMETER 

I  R0  =  SUCCESS  CODE 


LOCAL 

INDEX 

WORD 

DBR  NO 

WORD 

ACCESS 

VCRD 

G  AST  BASE 

ADDRESS 

ENTRY 

LD 

INDEX,  R0 

LD 

DBR 

NO,  Rl 

LD 

ACCESS,  R2 

LD 

R5, 

#G  AST 

LD 

R13, 

,  #SIZEOF  G  AST  EEC 

MULT  RR12,  R0 

ADD 

R5, 

,  R13 

LD 

G  AST  BASE,  R5 

ADD 

R5, 

,  #16      !  SIZE 

OFFSET  I 

CLR 

R6 

LD 

R7, 

,    3R5 

DIV 

RR6,  #BLK  SIZE 

LD 

R6, 

R7 

DEC 

R5, 

,  #12      !  L  AST 

INDEX  OF 

LD 

R7. 

GR5 

LD 

R0, 

Rl 

LD 

Rl, 

R6 
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CALL   CHECK  MAX  VIRTUAL_CORE 
CP   R0.  #VIRTUAL_CORE_IULL 
IF   EQ   THEN 
RET 


n 

INC 

R5 

.  #4 

!  NO  ACTIVE  IN  MEMORY  OFFSET  ! 

INC 

0R5,  #1 

LD 

Ee, 

0R5 

CP 

ACCESS, 

#WRITE 

IF 

EQ 

THEN 

DEC 

R5 

,  #4     I   OFFSET  TO  FLAd  BITS  ! 

LD 

R4, 

GR5 

OR 

R4, 

#WRITA3LE  MASK 

LE 

GR5 

,  R4       " 

FI 

LD 

R0, 

R7 

CALL   CHECK 

LOCAL  MEMORY 

AND 

R4 

,  #WRITABLE  MASK 

CP 

R4, 

#0 

IF 

NE 

THEN 

CP 

R8, 

#1 

IF 

GT 

THEN 

CP 

Ee,  #IN  LOCAL  MEMORY 

IF 

NE   THEN 

LD   R0,  R6 

CALL   ALLOC  LOCAL  MEMORY 

CP   R0,  #LOCAL  MEMORY  FULL 

IF   EQ   THEN 

RET 
FI 

LD   R9,  Rl 

INC   R5,  #8      !  PAGE  TABLE  LOC  OFFSET  I 
LD   R0,  CaR5 
CALL   READ  SEGMENT 
CP   R0,  #VALID 
IF   NE   THEN 

LD   R0.  R9 

LD   Rl,  R6 

CALL   FREE  LOCAL  BIT  MAP 

RET 
FI 

LD   R10,  #L  AST 
LD   R13,  #SIZEOF  L  AST  REC 
MULT   RR12,  R7 

ADD  R10,  R13  IMEMORY  ADDR  OFFSET  INTO  L  AST! 
LD   OR10,  R9 

ELSE 

LD   R10,  #L  AST 

LD   R13,  #SIZEOF  L  AST  REC 

MULT   RR12,  R7 

ADD   R10,  R13 
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LD   R9,  GR10 
FI 
FI 
ELSE 

LD   R8,  E0 
LD   R5,  G  AST  BASE 

INC   R5,  #2    !  GLOBAL  ADDR   OFFSET  ! 
LD   R12,  0R5 
CP   R12,  #NULL 
IF  EQ  THEN 
LD   R0,  R6 

CALL   ALLOC_GLOBAL_MEMORT 
CP   R0,  #GLOBAL  MEM  FULL 
IF   EQ   TEEN 

RET 
FI 

LD   R9,  Rl 

CP   R8,  #IN_LOCAL_MEMORI 
IF   EQ   THEN 
LD   R0,  R7 

INC   R5,  #14    !  SIZE   OFFSET  ! 
LD   R2,  GR5 
CALL   MOVE_TO_GLOBAL 
CP   R0,  #VALID 
IF   NE   THEN 

RET 
FI 
ELSE 

LD   R0,  Rl 
LD   Rl,  INDEX 

CALL   SIGNAL_OTHER  MEi-iORY_MA.MAGERS 
CP   R0,  #VALID 
IF   NE   THEN 
RET 


FI 


FI 


ELSE 

LD   R5  ,G  AST  BASE 

ADD   R5,  #2   "!  GLOBAL_ADDR  OFFSET  ! 

LD   R9,  GR5 
FI 
FI 

LD   R0,  DBR  NO 
LD   R10,  #L'AST 
LD   R13,  #SIZEOF  L  AST  REC 
MULT   RR12,  R7     ~    ~ 
ADD   R10,  R13 
ADD   R10,  R0 
INC   R10,  #2 
LDB   RLl,  ORie 
LD   R2,  R9 
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LD   R3,  ACCESS 
LD   R4,  R6 

CALL   UPDATE  MMU  IMAGE 
LD   R0,  R7   ~    " 
LD   Rl.  ACCESS 
LD   R2,  DBR  NO 
CALL   UPDATE_L  AST  ACCESS 
LD   R0,  #SWAPPED  IN 
END  SVAP_IN 

MAIN_LINE   PROCEDURE 

ENTRY 

CALL  SVAP_IN 

CALL  H3UG 
END  MAIN_LINE 
END  MEM  MGR 
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